Firebase Development Training in Pune with Placement

What Firebase actually is after the Google Cloud consolidation: a set of managed services sitting on the same projects, IAM and billing as the rest of Google Cloud, rather than a separate product. The product map is worked through so that later choices are informed — Authentication, Firestore, Realtime Database, Cloud Functions, Cloud Storage, Hosting, Cloud Messaging, Crashlytics, Analytics, Remote Config — with the question each one answers.

The project is then set up the way a team would rather than the way a tutorial does: separate projects for development, staging and production, the Firebase CLI and project aliases, configuration kept out of source control, and the Local Emulator Suite running Auth, Firestore, Functions and Storage on the laptop. The emulator is treated as the daily driver from week one, because developing against a live production project is how student projects lose data and run up bills.

Identity, which every other Firebase feature depends on because security rules are written against it. The provider set is built out in class — email and password with verification and reset, phone and OTP as the dominant flow in India, Google, Apple, GitHub and Microsoft federated sign-in, and anonymous accounts later upgraded to a permanent identity without losing the user's data.

The token model is then made explicit: the ID token, its expiry and refresh, and how it reaches both security rules and your own backend. Custom claims are used for role-based access, with the propagation delay that catches people out; the Admin SDK verifies tokens server-side; and custom tokens integrate an existing authentication system. Multi-factor authentication, account linking, and the session and sign-out edge cases close the module.

Firestore's model in its own terms: documents, collections and subcollections, document references, the 1MB document limit, and the field types that differ from plain JSON — timestamps, geopoints, references and arrays.

Queries are then taught alongside their constraints, because Firestore's limits are the thing that most shapes a design. Equality and range filters and the single-range-field rule, `orderBy` interaction, `array-contains` and `in` with their element caps, cursor pagination with `startAfter`, and the composite indexes the console asks you to create. Real-time listeners are contrasted with one-off reads on both cost and behaviour, `count`, `sum` and `average` aggregation queries are used to avoid reading a collection to size it, and transactions and batched writes complete the module.

Modelling for a database billed per document read, where the cost of a design is visible on an invoice. Denormalisation is the default rather than a compromise: duplicate the fields a screen needs so the screen is one read, and keep the copies consistent with a Cloud Function. Root collections against subcollections, and the collection-group query that makes subcollections searchable across parents.

Counters and aggregates are held as fields rather than computed on read, with distributed counters for the write-rate ceiling of one sustained write per second per document. The write-hotspot problem is demonstrated — sequential document IDs concentrate writes on one index range — along with fan-out for feeds, the security-rules-driven access model that constrains schema shape, and pagination designs that stay cheap.

The module that decides whether an application is safe, and the one most Firebase tutorials skip. Firestore and Storage rules share a language and a mental model: rules are not filters, an unauthorised query fails rather than returning fewer rows, and a rule that reads another document costs a read and can be denied itself.

The work is hands-on and adversarial. Rules are written for ownership, roles from custom claims, field-level validation and immutable fields; `get` and `exists` lookups are used for membership checks with their cost made explicit; and the Rules Playground and emulator unit tests turn rules into something with a test suite. The class then attacks its own project from a plain client SDK with a stolen user token — the exercise that makes the difference between rules that look right and rules that hold.

The behaviour that makes Firebase feel different to build on: an application that keeps working without a network. Offline persistence on mobile and in the browser, the local cache, latency compensation where a write appears instantly and reconciles later, and the pending-writes metadata a considered UI actually shows the user.

Conflict handling is worked through honestly — last-write-wins is the default, and transactions or server timestamps are what you use when that is not acceptable. Listener lifecycle and detachment are covered because leaked listeners are both a memory bug and a billing one. The Realtime Database is then compared with Firestore on query model, pricing and latency, with the cases where it is still the better choice, such as presence.

Server-side logic without a server to operate. Second-generation Cloud Functions run on Cloud Run, and the trigger types are covered with the job each one suits: HTTPS and callable functions for client-invoked work, Firestore and Auth and Storage triggers for reacting to events, scheduled functions for recurring jobs, and Pub/Sub and Task Queue functions for background work.

The operational realities are given equal weight, because they are what breaks in production: cold starts and minimum instances, concurrency and instance limits, idempotency for a trigger that may fire twice, retries and dead-lettering, and the infinite loop created by a function that writes to the document that triggered it. Secrets, the Admin SDK's privileged access, structured logging, error reporting and local debugging in the emulator complete the module.

Files and notifications, the two features almost every mobile brief includes. Cloud Storage covers upload and download with resumable transfers and progress, path design that lets a rule authorise by ownership, metadata and content types, signed URLs, and image processing triggered on upload so that thumbnails are generated server-side rather than on the device.

Cloud Messaging then covers the delivery path properly: device tokens and their rotation, topic and condition targeting, notification against data messages and how each behaves in foreground, background and terminated states on both Android and iOS, APNs configuration, deep links into the app, and delivery reporting. Rate limits, batching and the discipline of not sending a notification nobody asked for close the module.

Getting the web half of the product in front of users. Firebase Hosting for static and single-page applications — the global CDN, cache headers, rewrites and redirects, custom domains and automatic certificates, preview channels for pull-request review, and multi-site hosting from one project.

App Hosting is then used for framework-driven applications that need server rendering, with Next.js and Angular as the worked examples: the GitHub-connected build and deploy flow, server-side rendering against Cloud Run, environment configuration and secrets, and rollbacks. The module ends on release discipline — promoting the same build through staging to production rather than rebuilding, and the deploy pipeline in GitHub Actions that automates it.

The instrumentation that separates a shipped app from a maintained one. Google Analytics for Firebase covers automatic and custom events, event parameters and user properties, audiences, funnels and retention, the DebugView used to verify an event before release, and the BigQuery export that makes the raw event data queryable in SQL.

Crashlytics follows — crash and non-fatal reporting, symbol upload for readable stack traces, custom keys and logs that make a crash reproducible, and velocity alerts. Remote Config then turns configuration into a server-side decision with conditions, percentage rollouts and a kill switch for a feature that is misbehaving, and A/B Testing builds on both to run a real experiment with a stated metric. Performance Monitoring and App Check close the module.

The two additions that changed what a Firebase backend can be asked to do. Genkit is the framework for AI features: flows as testable units, Gemini model calls, structured output with a schema so the response can be trusted by the calling code, retrieval-augmented generation over your own Firestore data, tool calling, and the developer UI for tracing and evaluating a flow. Flows are deployed as Cloud Functions and rate-limited, with cost and prompt-injection risk treated as engineering concerns rather than footnotes.

Data Connect then covers the case Firestore is wrong for: a managed PostgreSQL database inside a Firebase project, with a schema, GraphQL-shaped queries and mutations, generated typed SDKs, and authorisation expressed alongside them. The judgement is the point — relational integrity, joins and reporting belong in Data Connect; documents, real-time and offline belong in Firestore, and a real application often uses both.

The module that stops a working prototype from becoming an expensive incident. Firebase bills per operation, so cost is a design property: a listener attached to a large collection, an unbounded query, a counter updated on every page view, or a trigger that writes back into its own collection are each traced from code to line item, with budget alerts and quota limits configured as a backstop.

Production readiness is then run as a checklist against each student's own project: security rules tested rather than assumed, App Check enforced so the backend only answers the real app, indexes declared in source control, backups and Firestore point-in-time recovery, IAM tightened so nobody develops with owner rights, monitoring and alerting, and a documented incident path. Vendor lock-in and an honest exit strategy close the module.

The capstone is a complete product on Firebase: authenticated users, a Firestore model designed for its read patterns, security rules with a test suite, Cloud Functions for the logic that cannot live on the client, file upload with server-side processing, push notifications, one Genkit AI feature, analytics and Crashlytics wired in, and a web client deployed on Hosting or App Hosting — released through a pipeline with a staging project in front of production.

Interview preparation targets what Pune panels ask a Firebase candidate, which is rarely trivia: model this feature in Firestore and justify the reads it costs, write a security rule for this requirement, explain what happens to this write offline, and say where Firebase would be the wrong choice. Resume, LinkedIn and GitHub are rewritten around the capstone, and two mock interviews are run and reviewed.