DEV Community: Akilah Littlejohn

LLM APIs as Infrastructure: Building Deterministic Systems Around Probabilistic AI

Akilah Littlejohn — Sat, 04 Jul 2026 22:06:58 +0000

The nature of an AI API

Somebody built this thing before you ever touched it. A lab trained it on an enormous amount of text, aligned it, wrapped it behind an endpoint, and rented it to you. You don’t own the model. You inherit the interface: its capabilities, its limits, its context window, and its cost.

When you send a prompt, the model has two sources of information: what it learned during training and the context you provide. Training is fixed. Context is yours. From those two inputs, it produces the most probable continuation.

People hear “probable” and think “guessing.” But it isn’t guessing like a coin flip. It’s producing the most likely continuation given everything the model has learned and everything you just told it — a weighted, structured output shaped by patterns and distributions.

Most of the time, that’s useful.

Sometimes, it’s confidently wrong.

If it gets something wrong, that does not mean there is a bug waiting to be patched.

It’s the behavior you have to design around.

Beyond the API call

Traditional APIs train us to think in predictable systems: send a request, expect a response. Even complex systems have repeatable behavior. There may be state management, caching, retries, and rate limits, but your code usually knows what success and failure look like.

AI systems break that expectation at the model layer. Same prompt, same context, but different output. Not because something failed. Because that's how the component works. The request can succeed, the response can be 200 OK, the JSON can validate, and your logs can look clean, yet the answer can still be wrong. Hallucinations, dropped instructions, valid JSON with incorrect data. Nothing technically failed. The model simply produced the wrong output. That shifts the focus from whether the system responded to whether the response is right.

Traditional APIs usually fail in ways your code already knows how to handle. The request either resolves or rejects, and your error handling catches both.

try {
  const response = await fetchClaim(id);
  renderClaim(response);
} catch (error) {
  showError(error);
}

Traditional software encourages a simple mental model:

Request → Response → Done

AI systems need more checkpoints between the user's input and the final output — and a separate quality gate before anything ships at all.

Runtime (every request):
User Input → Prompt/Context → LLM → Structured Output → Schema Validation → Business Rules → UI

Pre-deployment (CI/CD):
Test Dataset → Full Pipeline → Eval → Pass/Fail Gate → Deploy

The API call is only one step. The model is only one part. It is not the whole app.

Where determinism matters

In a probabilistic system, determinism matters when the output becomes data, triggers an action, or changes the state of the application. If a user says, "I got rear-ended yesterday," the assistant can explain the interpretation in different ways. But the submitted incidentDate cannot be different every time. The system needs one resolved value, one validation path, and one record of what was submitted. The wording around the field can be flexible — the value that enters the system cannot.

Lock these down:

Final form fields: incidentDate, injuries, accidentType
Required fields: whether something is complete or missing
Business rules: whether the form can be submitted
Actions: sending the form, saving a record, approving a claim
Audit/history: what value was used and why

Let these breathe:

The assistant's wording
The explanation shown to the user
Suggestions for what to clarify
Summaries or labels that do not trigger action

The boundary in practice

Every step between the model and your user is a layer you own and control. Here's what that looks like in a real integration.

In a form application, the model can help turn a user's plain language into structured data. A user might write:

"I got rear-ended yesterday. My side mirror broke, but nobody was hurt."

The application expects this shape:

interface IncidentExtraction {
  formData: {
    incidentDate: string;
    accidentType: string;
    damageDescription: string;
    injuries: "Yes" | "No" | "Unclear";
    notes: string;
  };
  feedback: string[];
  confirmation: string;
}

But the model does not receive a TypeScript interface. It receives instructions and a strict schema.

import { GoogleGenAI, Type } from "@google/genai";

const ai = new GoogleGenAI({});

const incidentSchema = {
  type: Type.OBJECT,
  properties: {
    formData: {
      type: Type.OBJECT,
      properties: {
        incidentDate: {
          type: Type.STRING,
          description: "Resolved date in YYYY-MM-DD format."
        },
        accidentType: {
          type: Type.STRING,
          description: "Short classification of the incident."
        },
        damageDescription: {
          type: Type.STRING,
          description: "Brief description of the damage."
        },
        injuries: {
          type: Type.STRING,
          enum: ["Yes", "No", "Unclear"],
          description: "Whether injuries were mentioned."
        },
        notes: {
          type: Type.STRING,
          description: "Any additional relevant details."
        }
      },
      required: ["incidentDate", "accidentType", "damageDescription", "injuries", "notes"]
    },
    feedback: {
      type: Type.ARRAY,
      items: { type: Type.STRING },
      description: "User-facing notes about assumptions or missing details."
    },
    confirmation: {
      type: Type.STRING,
      description: "Short message asking the user to review the filled form."
    }
  },
  required: ["formData", "feedback", "confirmation"]
};

const today = "2026-07-02";

const prompt = `
Today is ${today}.

Extract incident details from the user's description.

User description:
"I got rear-ended yesterday. My side mirror broke, but nobody was hurt."

Rules:
- Resolve relative dates using today's date.
- If a field is unclear, use "Unclear" or an empty string.
- Do not submit the form.
`;

const response = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: prompt,
  config: {
    responseMimeType: "application/json",
    responseSchema: incidentSchema,
    temperature: 0.1 // Lower temperature for more consistent extractions
  }
});

The schema shapes the output. It does not guarantee it. Everything after this line is your code enforcing your rules:

let result: IncidentExtraction;

try {
  result = JSON.parse(response.text);
} catch {
  // Unparseable output. Do not guess. Fall back.
  return askUserToFillManually(
    "I couldn't process that description. Please fill in the form directly."
  );
}

const { formData } = result;
const issues: string[] = [];

// The schema said "YYYY-MM-DD." Verify it anyway.
if (!isValidDate(formData.incidentDate)) {
  issues.push("Incident date could not be resolved.");
}

// Business rule the model knows nothing about.
if (formData.incidentDate > today) {
  issues.push("Incident date cannot be in the future.");
}

// Enums are enforced by the schema — trust, but verify.
if (!["Yes", "No", "Unclear"].includes(formData.injuries)) {
  issues.push("Injury status is unclear.");
}

if (issues.length > 0) {
  // Bad data never renders as truth. The user resolves it, not the model.
  return askUserToReview(formData, issues);
}

renderForm(formData, result.feedback, result.confirmation);

With the schema in place, the model can return a clean string matching your structure:

{
  "formData": {
    "incidentDate": "2026-07-01",
    "accidentType": "Rear-end collision",
    "damageDescription": "Broken side mirror",
    "injuries": "No",
    "notes": ""
  },
  "feedback": [
    "I interpreted \"yesterday\" as July 01, 2026.",
    "I marked injuries as No because the user said nobody was hurt."
  ],
  "confirmation": "I filled in the form based on your description. Please review before submitting."
}

Key practices for reliability:

Use structured output with a strict schema.
Always validate the output in your code — schemas are very helpful but not 100% guaranteed.
Include a feedback array for transparency.
Fall back gracefully when parsing or validation fails.

This is the boundary. The model interprets language. Your system owns execution and remains the source of truth.

Testing with Evals

The validation above protects each request. It says nothing about whether your pipeline is good overall — that's what evals are for.

With normal software, you test whether something works or fails. With AI, you also need to test whether the answer is good enough.

Evals let you run a test dataset through your pipeline, measure quality against a clear bar, and catch weak outputs before changes reach users.

const results = await Promise.all(
  testDataset.map(test => extractIncidentFromLLM(test.input))
);

const accuracy = results.filter((r, i) =>
  r.formData.injuries === testDataset[i].expectedInjuries &&
  isValidDate(r.formData.incidentDate)
).length / testDataset.length * 100;

if (accuracy < 95) {
  throw new Error(
    `Eval failed: accuracy dropped to ${accuracy.toFixed(1)}% (threshold: 95%)`
  );
}

Best practices: Include edge cases, ambiguous language, and adversarial inputs. Track schema compliance, hallucination rate, and feedback quality. Run evals in CI/CD.

In a real pipeline, you'd replace Promise.all with a concurrency-limited runner that handles retries and failed requests, so the eval tests the system without overwhelming the provider. A production eval keeps a separate score for each thing that can go wrong — like a report card instead of a GPA — so when the numbers drop, you know exactly what to fix.

Closing

The mistake is treating the model as though its job is to know the answer. Knowing was never the point.

Treat the LLM API as infrastructure. Like a database, a message queue, or an API gateway, it has capabilities, constraints, and mechanics.

Your job is not to make the model deterministic. It's to design the architecture around it so that probabilistic outputs become safe, predictable, and useful.

Google I/O 2026: Stop Writing Google Off. The Agentic Bet Most People Are Missing.

Akilah Littlejohn — Wed, 03 Jun 2026 21:27:33 +0000

When Gemini was launched as Bard, a lot of people criticized it as being rushed and slow, a sign that Google couldn't compete. After a messy couple of years, Google's story finally holds together: multimodal first, deeply embedded in Workspace, and now agentic infrastructure at scale. They were figuring out where AI fits inside a 25-year-old product empire (Search, Workspace, Android, Cloud) all at the same time. Google was doing something most companies can't afford to do: take public criticism while repositioning.

That pattern is playing out again. Google is getting a lot of early criticism for changing Search and its approach to Agentic Development, but I think some of that criticism may be premature. What looks like disruption may actually be Google case-testing how search should evolve so it can stay competitive and future-proof the company. With that said, here are a few thoughts from my favorite key points from the Google I/O keynote, which I got the chance to see live.

✅ Gemini + Gemma: Pros

Google's AI model strategy feels increasingly accessible and flexible. Gemini for managed AI, agentic workflows, and cloud orchestration, and Gemma for openness, portability, and privacy. Google is approaching both sides of the market. It's cool to see how they're building an exclusive ecosystem while also modernizing the agentic workflow. With Gemini Sparks, an autonomous 24/7 background agent available through the AI Ultra tier, you can now have Gemini-powered agents doing tasks and automations even while offline. The release of model weights under Apache 2.0, including Gemma 4, means developers and organizations have a more open path to run AI locally or inside their own secure infrastructure when privacy, compliance, or regulatory requirements matter. And with the Agent platform (formerly Vertex AI), developers can work across multiple models and providers with the option to run AI completely outside of Google's cloud ecosystem.

❌ Gemini + Gemma: Cons

Google and the industry as a whole will have to continue making the case for premium AI subscriptions, as lower-cost APIs and open ecosystems, including many coming out of China, keep pushing capabilities at dramatically lower prices. That said, Gemma 4 is an open-source model you can use safely at the enterprise level locally, which is Google's own answer to that pressure.

⚡ Antigravity Platform: Pros

Google isn't positioning Antigravity as just another AI coding IDE. Beyond the desktop experience, it extends into a CLI, SDK, API, and managed agents, while also including verification tools to help developers review output. Instead of competing strictly on specialized code editing like Cursor, or rapid terminal-based reasoning like Claude Code, Antigravity 2.0 tries to solve the whole workflow, plan, execute, test, and report back. It's essentially a multi-agent orchestration platform that supports parallel work through dynamic subagents, which can split tasks and run them simultaneously. I had actually built my own app based on this concept, not just assigning multiple agents to tasks, but having them work and communicate together on a task. Honestly, it's pretty dope to use a platform that integrates so much of the workflow I already wanted in one place.

⚠️ Antigravity Platform: Cons

It may be too agent-first for people who still want a normal IDE workflow. Direct code editing has been entirely removed from the primary interface, so you're forced into automated tasks with a real sense of lost control. I like having access to the terminal and being able to fix minor things manually, and what I hate the most is that visual indicators for inline warnings or errors on files are completely gone. There's also a learning curve, managing the system feels entirely different from traditional programming. You're not just writing code, you're managing a fleet of AI agents working at the same time. And because those agents use a lot of compute and tokens, it can get expensive, which is partly why Google introduced that $100/month Ultra tier for heavy users.

🛍️ Agentic Search: Pros

My personal favorite from the keynote. Google is now leveraging the same Antigravity-powered infrastructure that powers its development platform to dynamically build experiences around user intent rather than simply returning static results. The search engine uses Antigravity background subagents to fetch real-time web APIs, design an interactive frontend, spin up a secure sandboxed execution environment, and serve you a fully functioning web app in seconds, right inside your search results. It's both exciting and a little scary. This is the one that should keep every SaaS founder up at night. It collapses entire categories of simple-use-case tools. Why navigate to a unit converter, currency calculator, or lightweight data viz tool if the search result is the tool?

🔍 Agentic Search: Cons

The rise of agentic search is quietly reshaping the SEO landscape in a way that goes beyond just rankings. Google can now answer queries directly, build interactive tools inline, and keep users inside its ecosystem entirely. Your site may be sourcing the answer without ever getting the visit, fewer clicks, fewer page views, fewer ad impressions. Smaller publishers feel this the hardest since they depend on traffic volume more than brand authority. The rules of SEO are changing. It's no longer just about ranking, it's about being visible inside the AI answer itself.

📱 Google AI Studio: Pros

What stood out to me is how much friction Google is removing from prototyping. AI Studio can now generate Android apps, preview and test builds directly in the browser, connect with Workspace tools like Docs and Sheets, and deploy projects to Google Cloud and Google Play without ever leaving the platform. It even runs an Android emulator directly in your browser to test your build. For anyone who's dealt with the usual environment setup headaches, this is a significant shift.

🚧 Google AI Studio: Cons

It still has backend and scaling gaps. It's strong at helping you build the frontend and prototype quickly, but more complex apps still need extra work for databases, auth, permissions, and production-grade infrastructure. There's also a privacy tradeoff on the free tier, since your usage may be handled in ways that aren't ideal for sensitive or commercial work.

Conclusion

Ultimately, the same way people wrote Google off during the Bard era and were proven wrong, I think the current wave of criticism around Search and Agentic Development may age just as poorly. Google's bet is that the future of AI is a race to build the core operating system for an agentic world. By rapidly improving Gemini's latest models' multimodal capabilities, and leveraging their open model ecosystem with things like Gemma 4, they are securing both sides of the developer market.

Capturing that ecosystem early means they don't need a viral consumer breakout. They can inject their AI infrastructure directly into the tools developers already use to build the world's software. Google knows it doesn't need to build every consumer application to win the AI race. If they can make Gemini's latest models and Antigravity 2.0 the fastest, cheapest, and most robust orchestration layer for other people to build on, they can win by default.

Runner H Ai

Akilah Littlejohn — Mon, 09 Jun 2025 07:41:30 +0000

Why Angular's Opinionated Approach Clicked For Me!

Akilah Littlejohn — Tue, 09 Jan 2024 01:06:49 +0000

From Junior Developer to Angular Advocate: A Journey in Code Architecture

My background being involved in Opensource and Community Projects has made me obsess with organized code. In that setting, you have developers who come in and out of the project constantly, several junior developers taking their first steps with a large code base (including myself) and no dedicated engineering manager causing the architecture of these applications to be done on the fly. These codebases using other ui/js libraries got messy and often the tech stack would grow and get confusing as problems evolved. While it's safe to say that the messiness of code bases and the complexity of tech stacks aren't initially caused by JavaScript libraries themselves, these issues often arise as developers grapple with problems that extend beyond simple DOM manipulation—challenges that, quite frankly, beginners aren't yet equipped to handle effectively.

While I started learning Angular working with a friend on his personal projects, I started to see the point of learning design patterns and reactive paradigms. I didn't have to focus so much on coordinating simple state changes across my app and realized how much I relied on Typescript for the assistance it offered through my IDE's intelligent code completion and refactoring features. Eventually, I wanted to introduce Angular to every project because I saw the solutions that it offered. Unfortunately, at the time Angular had a steeper learning curve compared to some other frameworks (I dont believe that is the case anymore) . I continued to learn on my own time and grew to love Angular’s structured approach, combined with its All-inclusive toolset and community support.

Key aspects of its architecture and development philosophy.

Angular is often described as an "opinionated" framework, which means it has a strong point of view on how applications should be structured and built. Ultimately, whether Angular's opinionated nature is a benefit or a drawback depends on your individual preferences and project needs. Here are some ways in which Angular's opinions are reflected

1. Component-Based Architecture:

Building UIs with reusable components is like playing with Legos. You can create complex things easily by snapping together reusable pieces. Each component consists of an HTML template that declares how that component renders, a TypeScript class that defines behavior, and a CSS selector that defines how the component is used in a template.Encapsulating their own logic and design.Separating concerns keeps your code tidy, focused, and easy to maintain, like having different rooms for different tasks in your house.

2.Services and Dependency Injection:

Services offer focused functionalities, and Dependency Injection lets you plug them into your code like building blocks, making it flexible and adaptable.They live outside your components and handle tasks like fetching data, logging activity, or performing calculations, keeping your components clean and focused on the user interface. Think of it as dividing chores so everything runs smoothly

3.Directives:

Angular has three kinds of directives: components (which are directives with a template), structural directives (which change the DOM layout by adding and removing DOM elements), and attribute directives (which change the appearance or behavior of an element, component, or another directive). These directives extend the HTML in your application and give you the power to create complex behaviors in a declarative way.

4.Data Binding:

Angular provides a way to bind data properties of the component to the HTML template. This can be one-way (from component to view, or view to component) or two-way, which allows for interactive applications without having to write a lot of boilerplate code.

5.Routing:

The Angular Router enables navigation from one view to the next as users perform application tasks. It's based on a URL-based navigation scheme where each component is associated with a route. This system allows for the creation of single-page applications where navigation between different components doesn't require loading a new page.

6.TypeScript-Based:

Angular applications are built using TypeScript, which provides benefits like static typing, interfaces, and decorators. This enhances code quality and readability, and integrates well with Angular's dependency injection and component system.

7.Tooling:

The Angular CLI (Command Line Interface) is a powerful tool that enhances the Angular organized approach. It can generate code, run tests, and bundle applications for deployment, ensuring that these processes follow the Angular best practices.

Start your own Angular Journey

By enforcing specific patterns and practices, Angular ensures that different projects follow similar structures. This consistency made it easier for me to understand and contribute instantly. If you're curious about whether you'd enjoy working with Angular, I recommend trying out some tutorials and exploring the community to see if it sparks your interest.The Angular Team has really put more focus on the developers learning journey. The new docs on the new domain Angular.Dev have video tutorials, an IDE you can work with in the browser, and other resources catered to beginners.

Dedicated communities such as AngularNation, which offers curated learning resources and expert connections through selective membership, foster collaboration and skill development within a high-quality developer community. Additionally, the Angular Community Discord provides open-access, real-time support, casual discussions, and social connections. These are invaluable resources that I use personally that offer a sense of community and collaboration pushing the Angular ecosystem forward. This framework really is dear to me, I believe it made me a better developer in so many ways. You might be surprised at how much fun you can have building with this powerful framework!

Let's Connect

If you have any questions or feedback, please don't hesitate to drop them in the comments below or reach me personally.

Providers and importProvidersFrom() with Standalone Components

Akilah Littlejohn — Sat, 01 Apr 2023 05:25:50 +0000

In my last article we talked about how to initiate our applications with the bootstrapApplication() function. Today we are going to take a very brief overview of Angular Providers, its configuration, provider scope and how the new Standalone Api handles Angular providers using the importProvidersFrom() inside bootstrapApplication().

What are Angular Providers

In Angular, providers are used to define how a dependency should be instantiated. A provider can be any object or value, but most of the time, it is a class that provides a service or functionality. There are several ways to define providers in Angular, including the providers array in an Angular module, the providers property in a component decorator, or by using the @Injectable decorator to define a service.

Angular Provider Scope

In Angular, the provider scope refers to the scope at which a provider is registered and available for injection. The different levels of scope determines where in the application our providers are available.

Here is an example of how each scope may look like:

Root scope: When a provider is added to the root application Module it is available throughout the entire application.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { UserService } from './user.service';
import { AppComponent } from './app.component';

@NgModule({
  imports: [BrowserModule],
  declarations: [AppComponent],
  providers: [UserService], // Add UserService to providers array

  bootstrap: [AppComponent]
})

export class AppModule { }

Module scope: When a provider is added to a specific module's providers array, it is available to all components and services within "that" module. Our example for the module scope is pretty much the same as the example above for the root scope not including the bootstrap property.

@NgModule({
  declarations: [FeatureComponent],
  imports: [FeatureModule],
  providers: [DataService], // Add DataService to providers array
})
export class MyModule { }

Component scope: When a provider is added to the providers array of a specific component, it is available only to that component and its child components.

@Component({
  selector: 'my-component',
  template: `<h1>Hello, {{username}}!</h1>`,
  providers: [UserService], // Add UserService to providers array
})
export class MyComponent {
  username: string;

  constructor(private userService: UserService) { }

  ngOnInit() {
    this.username = this.userService.getUsername();
  }
}

When a component or service request a dependency, Angular's dependency injection system looks for a provider that can provide that dependency. If a provider is found, Angular creates an instance of the dependency and injects it into the component or service.

@NgModule({
  imports: [BrowserModule],
  declarations: [AppComponent],
  providers: [UserService], // Angular Finds provider.

  bootstrap: [AppComponent]
})

export class AppModule { }

// Any component can now inject the UserService.

import { Component } from '@angular/core';
import { UserService } from './user.service';

@Component({
  selector: 'app-root',
  template: `<h1>Hello, {{username}}!</h1>`
})
export class AppComponent {
  username: string;

  constructor(private userService: UserService) { } // <-- Injects service inside AppComponent's constructor.

  ngOnInit() {
    this.username = this.userService.getUsername();
  }
}

Providing Services with @Injectable()

Providing Services is probably one of the most common use case for providers. The @Injectable decorator is used to decorate a Service Class. The providedIn property located inside the object of @injectable specifies where a Service should be provided. The providedIn property takes a string value that specifies the injector for the service.

Here is an example of providing a Service in the Root Scope with @injectable():

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class MyService {
  constructor() { }

  // ... add methods and properties 
}

In the above code, we first import the Injectable decorator from the @angular/core module. Then, we use the @Injectable decorator to specify that the MyService class should be provided in the root scope. This means that there will be a single instance of the service that is shared across the entire application. Using the @Injectable_** provideIn:’root‘_ should be the preferred for method for making our services available through out the entire application similar to the Root Module. It takes advantage of Angular’s Injection system and is also treeshakable, the metadata tells the compiler which services are actually used in the application and which can be safely removed during the build process.

Provider's in a Standalone RootComponent

In the new bootstrapApplication call, it takes an object as the second argument that has a property named provider, similar to the provider flag in a Component or @NgModule. There, you can provide other Angular modules, such as those from a third-party library, for example, Angular Material or Angular's own libraries like the BrowserAnimationsModule using the new ImportProvidersfrom(). This function cannot be used in a Component or Module only in the bootstrapApplication call. Below is an example of how this property is set to an array that contains providers importing the MatButtonModule which is a module from the Angular Material library providing the necessary providers to the root component.

bootstrapApplication(AppComponent, { 
  providers: [importProvidersFrom(MatButtonModule)]
});

This was definitely a very shallow overview of what providers are and how to use them. I would suggest to learn more by looking at Angular's documentation. My next article covering the new Standalone Api we will learn how to get rid of route modules! If you have any questions or feedback, please don't hesitate to drop them in the comments below or reach me personally. Until next time! Thanks to Sander Elias, for providing helpful insights and being a resource for this article.

Bootstrapping Standalone Components

Akilah Littlejohn — Tue, 14 Mar 2023 02:33:23 +0000

A Glimpse of Life Without NgModules

This article is a brief overview of what it means to bootstrap your app, defining NgModules and a guide of how to initiate your apps without NgModules.

Bootstrapping Meaning and What are Ng Modules?

To "bootstrap" an application typically means to set up the initial configuration and dependencies required for the application to run.
Depending on the specifics of the application and the environment in which it is being developed or deployed determines what's needed to get your app up and running. It might involve installing necessary software libraries or frameworks, configuring database connections, setting up initial user accounts or permissions, and establishing default settings or configurations.
Overall, bootstrapping an application is an important step in the development process that lays the groundwork for development and deployment efforts.

NgModules

It is a Typescript class decorated with an "@NgModule" decorator. A NgModule can be thought of as a container and a way to organize related code such as components, directives, services, and pipes into a cohesive block of functionality.

Here’s an example of what a basic module might look like:

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';

@NgModule({
  imports: [BrowserModule],
  declarations: [AppComponent],
  bootstrap: [AppComponent]
})

export class AppModule { }

In this example, the @NgModule decorator is used to define a module called AppModule. This module imports the BrowserModule, which provides essential services for browser applications, declares the AppComponent, which is the root component of the application, and specifies that the AppComponent should be used as the bootstrap component.

Introduction to The Root Module and The Bootstrapping Process.

The root module is typically the starting point for bootstrapping the application and sets up the initial state of the application by creating the root component and injecting any necessary services. Imports any additional modules that the application requires and exports the components, directives, and pipes that should be available to other parts of the application.

Compilation Context

Explaining NgModules as just an organizing functionality is a bit of an understatement. Prior to Angular 9 one of the most important jobs of NgModules was the Handling of the Compilation Context.

What is the Compilation Context

Compilation context in Angular refers to the process of converting an Angular template into executable JavaScript code. It's a step in the Angular application's bootstrapping process that prepares the component templates for rendering by binding expressions and resolving dependencies. It involves three main tasks: template parsing, creating metadata, and generating a factory function.

The Bootstrapping Process in Detail

Angular uses a module system and requires that the AppModule be defined and imported in the application's entry point file in main.ts.

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { AppModule } from './app/app.module';

platformBrowserDynamic().bootstrapModule(AppModule)
  .catch(err => console.error(err));
In this example, the platformBrowserDynamic(

In the example above, the platformBrowserDynamic() function is used to bootstrap the AppModule module, which loads the AppComponent and any other components, directives, services, and pipes that are defined in the module.

Step 1: Create the root component -- This is typically done in the root NgModule, using the @Component decorator
Step 2: Inject necessary services --This is done by declaring the services in the providers array of the NgModule
Step 3: Import necessary modules_ -- This is done using the imports array of the NgModule_
Step 4: Attach the root component to the DOM -- This is done using the bootstrap array of the NgModule and passing in the root component

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { AppComponent } from './app.component';
import { MyService } from './my.service';

@NgModule({
  imports: [BrowserModule], // 2. Importing of other Modules
  declarations: [AppComponent],// 1. Create the Root Component
  providers: [MyService] // 3. Import of Services and other dependencies
  bootstrap: [AppComponent] // 4. Attaching the root Component to the Dom
})
export class AppModule { }

Why Would You Want to Replace NgModules?

NgModule concepts are more difficult to teach and learn for beginners.
Unnecessary complexity, it can be hard to debug and maintain, as they require a lot of boilerplate code.
Angular 9+ has the Ivy Compiler that provides Components with its own compilation context therefore application works without modules at runtime.

Life without NgModules using Standalone Components.

Now that we have some understanding of What NgModules are and why we don't need them at the start of our projects anymore, we can now go over Standalone Components and how you can begin using them at the beginning of your Angular Projects.

Lets Bootstrap our Root Standalone Component

import { Component } from '@angular/core';
import { CommonModule } from '@angular/common';
import { bootstrapApplication } from '@angular/platform-browser';
import { AppComponent } from './app.component';

bootstrapApplication(AppComponent);

In the example above you can already see how much simpler the code is. Here we remove the platformBrowserDynamic() and import the bootstrapApplication() instead and inject the App Component inside the function. Along with Components, Directives and Pipes can also be declared as Standalone. Standalone Component's, Directives and Pipes cannot be used in NgModules. Remember the compilation context let's see what that process looks like in a Component.

Here’s an example of what a basic Standalone Root Component might look like:

@Component({
  selector: 'app-standalone',
  standalone: true,//  1. instantiate standalone flag
  imports: [CommonModule, StandaloneComponent, ChangeSizePipe, 
            ColorDirective], // 3. Import Dependencies 
  templateUrl: './standalone.component.html' // 2.Render the Dom,
  providers:[MyService] // 4. Import of Services and other dependencies 


})
export class StandaloneComponent {
}

As you can see we have our standalone flag set to true, In the imports we have an array with a Directive and a Pipe. We also have the Common Module from '@angular/common' that provides us with the non standalone Directives ngIf, ngSwitch and a few others but we can only import Standalone Directives therefore we have to import the entire Module. That's it! this is all that is needed to get your Angular Application up and running
NgModule free.
There is alot more to learn about the new Standalone API that I didn't get to cover in this post but in the next article I can go over how to use importProvidersFrom(), provideRouter() and provideHttpClient() methods and the changes made with Routing. If you have any questions or feedback, please don't hesitate to drop them in the comments below. Until next time!

Top 3 Books That Leveled Up my JavaScript Skills.

Akilah Littlejohn — Mon, 22 Mar 2021 01:13:26 +0000

Unpopular opinion there is no such thing as a self-taught developer only self-motivated. Every last one of us, rather you are from a bootcamp, college educated, or a MOOC connoisseur such as myself have watched hours of tutorials, went through forums, and read tons of articles to learn the art of programming. All taught by someone. Constantly learning is our way and part of the journey. Lately, I have seen on numerous of social media posts and YouTube comments a piece of advice about learning that I find a little off putting. Its regarding learning from reading books. A lot of the advice I see is that "Most books are outdated because the industry is ever changing", "Books have to much techy jargon", or "Just watch tutorials it quicker". I would like to argue that reading books help you to digest ideas beyond an abstract level, help you form strong opinions, ( Which trust me you will need, imposter syndrome gets real.) and provide you with a more lengthy context of why things are the way they are that you cant always get with a video tutorial that are designed to teach concepts quickly. Sometimes just like with the English language we have "big words" that help us explain ideas more concisely. Techy jargon is needed so you don't speak in definitions. For example you can say, "Having the ability to know how others are feeling can help you with customer service" or you can say "Having empathy can help you with customer service". Also you have to understand that tech is in the business of solving problems which means if there are any big changes in the way something is done its making something easier to do and if not the new way isn't worth it. So reading outdated material is actually pretty fun to know how stupid things use to be and helps with having talking points with older Devs. If you haven't had the privilege a formal education and are self-motivated like me you want to make sure that you are not cheating yourself from having a quality learning experience. So with all that being said here are my top 3 books that I feel has help me become a better JS developer, I put them in the order that I thought was best to read them.

1. You Don't Know JS :Series

by Kyle Simpson

The original series of books was kind of a response to Douglas Crockford "JavaScript, The Good parts". If you read the O.G books you kind of got a feeling, that he thought if you think JavaScript has bad parts its because you don't know it. Some JS developers will never know the struggle of life before es6. JavaScript still has its quirks but this book will definitely help you with the weirder parts of JavaScript. If you want to learn how JS works behind the scenes and get a deeper understanding of the language these books will get you right and up to date, its updated often.

2. Maintainable JavaScript

by Nicholas C. Zakas

Probably my favorite book on JavaScript. It is an older book but this book has help me to be more mindful of how my code looks and works overtime. This book will help with having cleaner JavaScript and being a better team member for anyone you work with.

3. JavaScript Enlightenment

by Cody Lindley

This is another oldie but goodie, this book is about working with JavaScript Objects. I would suggest reading Kyle Simpson's "You Don't Know JS: this & object prototypes", first so that you know some of the more modern ways of dealing with objects with the es6 and beyond syntax. JavaScript is all about objects and have some unique ways with dealing with them. Read this book and JavaScript is so much easier to understand.

So that is my suggested reading for becoming a well read JavaScript master, which is like one of my ultimate goals in life.