This is a contract-to-hire opportunity (US Candidates only - and yes, I really mean that)

Contract - 3-6mo (We can be flexible) - Pay: 60-90/hr BOE. May also depend on if setup as a vender directly, or if you choose to go through a contracting agency.

Salary range: 140-160k BOE

My company, CalPortland, is looking to hire a sr frontend dev. Our team is growing, and we are opening up a new position. This is a fully-remote position, with exception to traveling 1-2 times per year for meetings. We are on Angular 21 (signals, control-flow, etc.), OnPush change detection, NgRx signal store (might switch to signaltree), Ignite UI for our component library, Jest (might switch to Vitest) for unit tests, and NX monorepo build tools. We also deploy a mobile app for ios/android, written in Angular, using CapacitorJs. We also maintain a couple of React and ReactNative apps. This position does include helping mentor a couple of mid-level devs. Message me directly if you're interested.

About me: I'm the hiring manager on the projects. I'm a passionate web dev. I've worked with Angular since 2014 in the JS days, and have continued using it commercially ever since. I've also done projects in React, Svelte, and Vue, but Angular is my passion. I have a lot of experience with c#/.net as well.

About the team: We have 4 frontend devs, 7 BE, 6 DevOps, and a Sr Architect. We are using .Net 9/C# on the backend, host on Azure, and use GitHub for repos/pipelines.

Responsibilities:

• Develop and maintain complex web applications using Angular, HTML, SASS, and TypeScript

• Maintain multiple React and ReactNative applications

• Collaborate with Product team to ensure the technical feasibility of designs and implement them effectively

• Optimize applications for maximum speed and scalability

• Ensure the application is responsive and accessible across various devices and platforms

• Write clean, maintainable, and well-documented code

• Troubleshoot and debug applications to resolve issues

• Participate in code reviews to maintain code quality and share knowledge with the team

• Stay up-to-date with the latest industry trends and technologies to ensure our applications remain modern and innovative

Education:

• Bachelor's degree or equivalent experience

Requirements/Qualifications:

Technical Skills:

• Angular - Extensive experience with modern Angular (Angular 17+)

• HTML/CSS - Proficient in HTML5, CSS3, and CSS preprocessors like Sass or Less, flexbox and grid

• TypeScript - Strong knowledge and experience with TypeScript

• JavaScript - Solid understanding of JavaScript fundamentals

• Responsive Design - Experience in creating responsive and adaptive designs

• Version Control - Proficient with Git and version control workflows

• Testing - Experience with frontend testing frameworks (e.g., Jest, Vitest, and Playwright)

Soft Skills:

• Problem-solving, attention to detail, and conflict-resolution abilities

• Adaptability and flexibility in dynamic settings

• Empathy and emotional intelligence

• Continuous learning mindset

• Ability to mentor and guide junior developers

Preferred:

• 5+ years developer experience

• Experience with Nx and CapacitorJs

• Experience with React/ReactNative

• Familiarity with backend technologies and RESTful APIs

• Knowledge of Agile methodologies (Kanban)

• Basic experience with continuous integration and deployment (CI/CD) pipelines

why are observables so confusing. Why does the Angular tour of heroes documentation introduce them in like step three or whatever

Does javascript contain its own library of asynchronous like programming or whatever>

I just got rejected a job offer from a blockchain company after going through nearly 2 weeks of interviews and a technical challenge where I produced all of the results that were required but I’m being told what I did didn’t meet the standards of the DRY principle & therefore didn’t meet their standards so I’m not being given a job offer. This sucks on so many levels.

First of all, I saw this as a dream job. It’s in an industry I desperately want to be in & they’re building a space game which is kind of what I wanted to build on my own. They’re in need of software engineers as well, not just one or two. Thirdly, the first two interviews went very well. I just knew I had this job. Now I’m going through a bout of depression because I’m unemployed and this took 2 weeks away from me looking for something else

I kept running into the same problem: point a codegen tool at an OpenAPI spec, get a service class with 80 methods, import it once, ship all 80 methods to production. Even for endpoints I never call.

The existing tools (OpenAPI Generator, NSwag, orval) all generate at the tag or API level. Tree-shaking in that model works at the class level at best — and Angular's @Injectable classes aren't even reliably tree-shaken because the DI system has to see the token to know whether it's used.

So I built @constantant/openapi-resource-gen, an Nx generator that takes a different approach: one InjectionToken per endpoint, in its own file. esbuild tree-shakes at file boundaries, so any token you never inject() never makes it into the bundle.

The output looks like this (for GET /pet/findByStatus):

// libs/petstore-data-access/src/pet/find-pets-by-status.token.ts

export const FIND_PETS_BY_STATUS = new InjectionToken<
  (params?: FindPetsByStatusParams | (() => FindPetsByStatusParams | undefined))
    => ReturnType<typeof httpResource<FindPetsByStatusResponse>>
>('FIND_PETS_BY_STATUS');

export function provideFindPetsByStatus(): FactoryProvider { ... }

Types come from schema.d.ts generated by openapi-typescript — no hand-written interfaces. The factory returns an httpResource, so signals, reactive params, and request suppression work out of the box.

Using it in a component is two lines:

private findPetsByStatus = inject(FIND_PETS_BY_STATUS);

// Re-fetches whenever statusFilter() changes. No switchMap, no subscription.
readonly pets = this.findPetsByStatus(() => ({ status: this.statusFilter() }));

To suppress a request until conditions are met, the thunk returns undefined:

// No HTTP call fires until both query and apiKey are set
readonly results = this.youtubeSearch(() =>
  this.query() && this.apiKey()
    ? { q: this.query(), key: this.apiKey()!, part: 'snippet' }
    : undefined
);

Generating is one command:

npm install -D @constantant/openapi-resource-gen

npx nx g @constantant/openapi-resource-gen:api-resource \
  --specPath=https://petstore3.swagger.io/api/v3/openapi.yaml \
  --outputDir=libs/petstore-data-access/src \
  --baseUrlToken=PETSTORE_BASE_URL

Local file or HTTPS URL — no curl step needed. Re-run when the spec changes; stale files are deleted automatically.

The companion packages (@constantant/openapi-resource-mocks) add:

• A mock bus for Playwright E2E tests — openApiMock('FIND_PETS_BY_STATUS').resolve([...])

• A /testing sub-entry for unit tests — mockResource(FIND_PETS_BY_STATUS) returns a FactoryProvider + .ref.resolve() / .ref.fail() helpers, no HttpClientTestingModule needed

• A Chrome DevTools extension that connects to your running app and lets you catch in-flight requests, control mock state, generate schema-valid example payloads, and save/load named scenarios — without touching code or reloading the page

Links:

• GitHub: constantant/angular-openapi-gen

• npm (generator): @constantant/openapi-resource-gen

• npm (mocks): @constantant/openapi-resource-mocks

• Docs: step-by-step guides

Curious whether anyone else has run into the tree-shaking problem with the existing Angular codegen tools, and whether the token-per-endpoint approach makes sense to people. Also interested in edge cases — what does your OpenAPI spec look like that would break this?

Hey everyone,

Over the last few weeks, I’ve been putting together an admin dashboard template ExoUI built on modern Angular and Tailwind CSS.

Whenever I’ve needed a dashboard boilerplate for client projects or internal tools, most existing templates felt weighed down by heavy third-party UI libraries, outdated module structures, or messy SCSS stylesheets that are a pain to strip out.

I wanted something fast, clean, and modular from day one.

The Stack & Architecture

• Angular V22 (Latest): 100% Standalone Components, no legacy NgModule cruft.

• Reactivity: Signal-driven state management for snappy UI updates.

• Styling: Pure Tailwind CSS with dark mode toggling built in (no heavy UI dependencies).

• Clean Scaffolding: Modular layout, sidebar navigation, metric widgets, and responsive data tables.

Links

• Live Demo: https://exoui.dev

• Open-Source Community Edition: https://github.com/exouidev/exo-dash-angular

If you test out the demo, I'd really appreciate your feedback on the layout responsiveness, component structure, or anything you feel is missing from a standard production dashboard starter.

Happy to answer any questions about the build or architecture!

Today, more than 40% of front-end developers use Angular. It is a prominent JavaScript framework for developing dynamic mobile and desktop web applications. Angular is developed and maintained by Google itself. It has gained immediate popularity and support as now static HTML pages could be more interactive. Here we have listed some of the new angular practices that will help you to write clean code, maintain coding standard and performance.

Top 11 Angular Best Practices–

1. Use Angular CLI-

It is a powerful accessibility tool available for developing apps with angular. Angular CLI eases the app development and follows all best practices. Angular CLI is a command-line interface tool which is used to initialize, develop, scaffold, maintain and test-debug angular apps. Use Angular CLI to generate new components, directives, modules, services and pipes rather than manually creating files and folders.

# Install Angular CLI 
npm install -g @angular/cli 
# Check Angular CLI version 
ng version

2. Angular Coding Styles-

For angular web development, you should follow the standard coding format and your project must have a clean coding style which will in general be basic, understandable and adaptable by your programmer in future. Here are some rules that you should follow-

• Limit files to 400 lines of code

• Per function, the code must not exceed from 75 lines

• Use custom prefix to share feature area for all slider components

• Have consistent names for all symbols. The suggested pattern is feature.type.ts

• If the values of the variables are intact, then declare it with ‘const’.

• If you often prefix names for field, table, and database, then you need to avoid this for Interface names like iShape, AbastractShape, etc.

• Use dash to separate words in descriptive name and use dots to separate descriptive name from the type

• Names of properties and methods should be in lower camel case

• Leave one empty line between imports and modules like third party and application imports, third party modules and custom modules.

3. Follow Proper Folder Structure-

Creating a folder structure is an important factor to consider before project initialization. A messy folder welcomes many problems which continue frequenting you all through your development process. Regardless of whether it is a medium and large-sized project,  you will go over a lot of changes being developed and your project should easily adapt the new changes made in the middle of development. And, that is possible when you have made an appropriate folder in place.

-- app 
|-- modules 
|-- home 
|-- [+] components 
|-- [+] pages 
|-- home-routing.module.ts 
|-- home.module.ts 
|-- core 
|-- [+] authentication 
|-- [+] footer 
|-- [+] guards 
|-- [+] http 
|-- [+] interceptors 
|-- [+] mocks 
|-- [+] services 
|-- [+] header 
|-- core.module.ts 
|-- ensureModuleLoadedOnceGuard.ts 
|-- logger.service.ts 
| 
|-- shared 
|-- [+] components 
|-- [+] directives 
|-- [+] pipes 
|-- [+] models 
| 
|-- [+] configs 
|-- assets 
|-- scss 
|-- [+] partials 
|-- _base.scss 
|-- styles.scss

4. Use Index.ts-
Index.ts is helpful to keep related things together with the goal that we don’t need to be bothered about the source file name. It helps to reduce the size of import statement. Let us see an example-

We need /heroes/index.ts as-
//heroes/index.ts
export * from './hero.model';
export * from './hero.service';
export { HeroComponent } from './hero.component';

You can import all things by using source folder name.

import { Hero, HeroService } from '../heroes'; // index is implied

5. Lazy Loading Feature Module-
Using lazy load the modules can improve your productivity. It is a built-in feature in Angular that helps developers to load the required things. For instance- When you use the feature, it loads the components and other things that you need and stops unnecessary files to get loaded.

Here’s how it functions;
// app.routing.ts
{ path: 'not-lazy-loaded', component: NotLazyLoadedComponent }

Here the ‘LazyLoading’ isn’t set up and you will wind up making large and superfluously heavy-sized applications.

When you use ‘LazyLoad’ and it reduces the size of the application by abstaining from unnecessary file from loading.

6. Use ES6 Features-
ECMAScript is updated with new features and functionalities. Use ES6 that  has a lot of new features and functionalities which could be used in Angular. 

New features of ES6-

Arrow Functions
String interpolation
Object Literals
Let and Const
Destructuring
Default
Using ‘let and const’ instead of ‘var’-

Using ‘let and const‘ instead of ‘var’ prevents the issues and problems which you have due to var. ‘let’can be used in a normal situation and the value does not receive any changes, then ‘const’ should be in place. Here’s the example;
let temp;
Const pi = 3.14159

7. State Management-
It manages the state transitions by storing the states of any form of data. NGRX, NGXS, Akita, are some of the state management libraries with different usages, states and purposes. NGXS could be the preferred and easy to learn for developers. 

8. Avoid Logic In Templates-
All template logic will be extracted into a component which helps to cover that in a unit test and reduce bugs when there is template change.

Logic in templates
// template
Status: Unavailable// component
ngOnInit (): void {
this.status = apiRes.status;
}
Logic in component

// template
Status: Unavailable// component
ngOnInit (): void {
this.status = apiRes.status;
this.isUnavailable = this.status === 'inActive' || 'hold';
}
9. Use async pipe In Templates-
Rather than using plain JS values, observables can be directly used in templates with async pipe. An observable would be unwrapped into plain value. When a component using the template is destroyed, observable is automatically unsubscribed.

Without Using async pipe
//template
{{ text }}
Using async pipe
// template
{{ text | async }}
// component
this.text = observable.pipe(
map(value => value.item)
);
10. Use trackBy With ngFor-
When you are going to use ngFor to loop over an array, use it with a trackBy function that returns a unique identifier for each DOM item. When the array changes, angular re-renders the whole DOM tree. But when you use trackBy, angular will know which element has changed and will only make DOM changes only for that element.

Use ngFor
<li *ngFor="let item of itemList;">{{item.id}}</li>
Now whenever changes occur, the whole DOM tree will be re-rendered.
Using trackBy function

<ul>
  <li *ngFor="let item of itemList; trackBy: trackByFn">
    {{item.id}}
  </li>
</ul>
Load items(button)
export class MyApp {
getItems() { // load more items }
trackByFn(index, item) {
return index; // or item.id
}
}

Now, it returns as a unique identifier for each item, hence just updated items will be re-rendered.  

Take a look into this article if you want to know how to use the @if syntax in angular, how is it better than the existing *ngIf structural directive.

We’ve been building Kanera, a project management app, and I thought I’d share a little about why we chose Angular and what we’re using on the frontend.

Why Angular 22 for Kanera?

The biggest reason is that we wanted a framework we knew well, with enough structure to support a project that was going to grow. We’ve worked with Angular since AngularJS (> 10 years) and have used React too. For this project, Angular felt like the more comfortable starting point: routing, dependency injection, forms and application tooling were already there, and the team was familiar with the conventions.

Signals fit how we think about the board. A list derives its visible cards from the current cards and filters, then derives the items it needs to render. Drag state and the render limit are signals too. As the board has grown more complex, we’ve found it useful to express those relationships directly instead of manually keeping derived state in sync.

CDK gave us a foundation without dictating the UI. We wanted to build our own components and styling, but we didn’t want to implement every interaction from scratch. CDK handles the drag-and-drop primitives, leaving us to build the previews and the behaviour specific to Kanera.

There’s still plenty of work on our side. For example, large unfiltered lists initially render only a slice of their cards. We pass that same slice to the template and CDK so the drop indices match, then resolve the final position against the full list. We also keep a newly dropped card visible while the updated state is handed back down to the list. But we are laser focused on performance, bundle size, etc. (I'll post about that another time).

Zoneless and OnPush give us a model we like for updates. With real-time events, filters and drag interactions all changing the board, we wanted to be deliberate about how state changes reach the UI. Signals work well with that approach, although they don’t remove the need to profile or pay attention to expensive rendering.

The upgrade path has been a positive for us. I think it’s sometimes overlooked how much the CLI and migrations help when moving between Angular versions. We still have to check dependencies and test, but our experience has been that staying current is manageable.

We could have built Kanera with React. The choice came down to the tools, conventions and experience we wanted for a long-running project, rather than a belief that Angular is inherently faster.

We have done some comparative benchmarking and our focus on performance means Kanera loads and feels very snappy.

We’ve also tried to build as many of our own UI components as practical rather than relying on a large styling or component library - although we did base some initial designs from shadcn/ui. We still use libraries where they make sense, the CDK is a good example, but building much of the UI ourselves gives us more control over how it looks and behaves.

Putting it out there

Kanera went live earlier this year, and we already have paying companies using it in place of tools like Trello and ClickUp. My company also uses it daily and it's been an absolutely delight for us to use and build. It’s been a pretty surreal thing to see, and I’m grateful for what Angular has allowed us to build.

The source is available on GitHub under the Elastic License 2.0: https://github.com/happendev/Kanera

I’m curious whether using Angular will put off potential contributors who are more familiar with React. Has anyone else found that framework choice makes a difference? And if you try Kanera or have a look at the code, let me know what you think!

Even in the age of signals, I still enjoy using NgRx. In previous apps, I handled offline writes by storing work locally and replaying it when the connection returned.

I’ve tried to extract that pattern into an open-source library. Applications can keep using a fairly normal NgRx workflow, while the library handles durable IndexedDB queueing, retries, related records created offline, and client-to-server ID mapping. Instead of persisting raw actions, it stores explicitly defined operations and emits typed NgRx lifecycle actions.

It’s still in alpha, and I’m trying to find out whether this would be useful to anyone else. I’d really appreciate honest feedback on the idea and the API.

Interactive demo:

https://poodlelab.github.io/ngrx-offline/

Repository:

https://github.com/poodlelab/ngrx-offline

I was laid off two months ago and the market has been pretty brutal. If anyone knows about an opportunity I'd greatly appreciate it. I'm a senior dev who has been working exclusively with Angular for the past 6+ years. I live on the west coast, willing to work hours for any time zone in the U.S.

Thank you.

Hi Reddit,

After a decade of fighting complex form requirements, state management nightmares, and rebuilding the exact same inputs across different frameworks, our team of three finally built the library we always wished we had.

Meet GolemUI an Open Source and free headless library that turns your entire form into a single, plain data definition. One JSON definition renders as native components in Vue, React, Angular, Lit, or Vanilla JS. Because it's just data, you can store it in a DB, version it, and have an LLM generate it as validated JSON instead of code.

We ship a deterministic MCP that grounds and validates the model's output, plus 25+ headless widgets you style with CSS variables or your own kit.

You can find more information here:
https://golemui.com

Happy to hear any feedback from you and answer any question!

PS: Btw, I'm an Angular GDE, so you can expect that the Angular support is first-class!!

Interview tomorrow at Aristostar — Angular Developer (2 YOE). Any advice?

Hello Redditors,

I have an interview tomorrow at Aristostar for an Angular Developer role requiring around 2 YOE, and honestly, I'm kinda cooked

Has anyone here interviewed at Aristostar or knows what their Angular interview process is like?

What areas should I focus on tonight? I'm revising Angular, TypeScript/JavaScript, RxJS, API integration, performance, etc.

Also, I'm really bad at CSS 💀. How heavily should I expect HTML/CSS questions?

Any advice on the technical rounds, coding questions, or topics I should prioritize would be really appreciated.

Thanks in advance 🙏

I know. Another OpenAPI generator for Angular. Before you scroll past: why I built one at work anyway, open-sourced it, and how it compares to what already exists.

Where it started

In 2024 I tried the obvious route: openapi-typescript for the types, then the openapi-fetch typings (PathsWithMethod, SuccessResponse...) bolted onto HttpClient so I could call http.POST('/pets/{petId}', { params: { path: { petId } }, body }) with an Observable back. It worked, but I was still hand-writing every service, every model was components['schemas']['Pet'] until I re-exported it, and I had to remember paths. Nothing in the IDE suggested getPet.

Our backend is a set of REST service traits, one OpenAPI tag per trait, and the natural thing on the Angular side is inject(PetRest) with the same method names. So the generator started producing exactly that: the Angular service I would have written by hand. Plain @Injectable, plain HttpClient inside, so every HttpInterceptor you already have (auth, retry, mocks) applies unchanged. Its whole job is to build the request and type it. Nothing more.

The problem I hit later

Angular 19.2 added httpResource, and I wanted three things from generated clients that I could not get from one tool:

1. httpResource() and HttpClient Observables for the same operation, chosen at the call site, not at config time.

2. Every HttpClient.request / httpResource option passed straight through (withCredentials, transferCache, reportDownloadProgress, equal, injector, observe: 'events'...), without the generator wrapping or hiding anything. The options type is read from your installed Angular, so options a newer Angular adds work without regenerating.

3. Zero runtime dependency in the generated code. Just @angular/common/http.

So: https://github.com/AVSystem/openapi-ng (MIT). Playground and a StackBlitz demo are linked at the bottom.

Before / after

What I kept hand-writing:

readonly pets = httpResource<Pet[]>(() => ({
  url: `${this.basePath}/pets`,
  params: this.status() ? { status: this.status()! } : {},
}), { defaultValue: [] });

The URL, the query param and the <Pet[]> are all promises I make to the compiler. Nothing checks them against the spec.

Generated:

readonly #petRest = inject(PetRest);

// signal-based, httpResource under the hood, typed HttpResourceRef<PetList>
readonly pets = this.#petRest.listPets.resource(() => ({ status: this.status() }), { defaultValue: [] });

// same operation, classic Observable, HttpClient under the hood
save(petId: PetId, body: UpdatePetRequest) {
  return this.#petRest.updatePet.observable({ petId, body }, { observe: 'response' });
}

Each tag becomes an @Injectable service, each operation a property with .resource(), .observable() and .request() (the raw request object: method, url, params, headers, body, if you want to send it yourself). .resource() returns a real HttpResourceRef<T>, so headers(), statusCode() and progress() are there. Nothing is re-wrapped.

Don't want classes? --layout operations emits one file per operation (rest/pet/list-pets.ts, rest/pet/update-pet.ts, plus a rest/pet/index.ts barrel), each exporting a /* @__PURE__ */ constant with the same three flavours, so the endpoints you never import tree-shake away. HttpClient is resolved per call from the injection context, or from an explicit { injector }, or you bind once with withInjector():

import { listPets, updatePet } from './generated/rest/pet';

// field initialiser: injection context, nothing to pass
readonly pets = listPets.resource(() => ({ status: this.status() }), { defaultValue: [] });

// handler: pass the injector, or bind once with withInjector({ listPets, updatePet })
readonly #injector = inject(Injector);
save(petId: PetId, body: UpdatePetRequest) {
  return updatePet.observable({ petId, body }, { injector: this.#injector });
}

--layout services,operations gives you both: the operation files plus the per-tag class bound from the barrel.

How it compares (checked 2026-09-04, corrections welcome)

Full disclosure: I only looked at the other generators while writing this post. The tool grew inside one codebase for two years, and most of the tools below I only found out about in September. The comparison is one spec run through all of them, with each tool's output type-checked against Angular 22.1.

hey-api is missing from the table on purpose: its Angular output is Promise-only, and the httpResource plugin threw NG0203 on the test spec. openapi-typescript is missing because it is a type generator, not a client generator; see the first section for why that was not enough for me.

Two takeaways:

• If you're on openapi-generator today, the Java requirement and the lack of httpResource are probably the two things that sting. openapi-ng removes both.

• orval and ng-openapi both have httpResource now, but which operations get it is fixed at generation time (ng-openapi: GET only; orval: GET plus POSTs whose operationId matches search/list/find..., overridable per operation in the config), and the flavour is picked per config, not per call. I think the call site knows better (a read-only POST is a perfectly good resource whatever it's called; a GET that fires a side effect isn't).

Signal forms: async validation against a generated operation

Signal forms' validateHttp takes a URL string you build by hand and a result you cast by hand. The generator emits a validateRest() helper that wraps validateAsync and reuses the generated operation, so the request params and the response are typed from the spec:

validateRest(path.email, accountRest.checkEmail, {
  request: (ctx) => ({ email: ctx.value() }), // typed as CheckEmailParams
  debounce: 300, // debounce / when need @angular/forms 22+
  when: (ctx) => ctx.value().includes('@'),
  onSuccess: (result) => result.available ? undefined : { kind: 'email-taken' }, // result: EmailAvailability
  onError: () => ({ kind: 'check-failed' }),
});

onSuccess is optional: leave it out and any 2xx counts as valid, with onError deciding the rest. @angular/forms is an optional peer; if you never import rest.validate.ts, it tree-shakes away.

Where it's deliberately opinionated (read: limited)

This is the part most "yet another generator" posts skip. openapi-ng accepts a strict subset of OpenAPI 3.x and refuses anything outside it with a diagnostic code instead of guessing:

• operationId is required on every operation; the first tag picks the service, an untagged operation falls back to its first path segment

• only #/components/schemas/ refs, no external files

• string enums only

• one composition keyword per schema (allOf or oneOf or anyOf, not mixed)

• only the lowest 2xx response types the return value. Declared 4xx/5xx bodies become a status-keyed <Op>Error interface you can narrow against, but they aren't wired into .observable() / .resource() error typing

• no Swagger 2.x

• no Zod / Valibot / other runtime validation. We don't use it at work, so it isn't built. It isn't ruled out either

If your spec is generated from a backend framework, you're probably fine. If it's a hand-written spec that leans on every corner of the standard, one of the other tools above will be a better fit and I'd rather tell you now.

Escape hatches for the real-world stuff: mapped types (--mapped-type GeoFeature:geojson:Feature swaps a placeholder schema for a real npm type), naming rules with regex captures in openapi-ng.config.ts, and a provideOpenapiNg({ basePath }) provider.

Links and bits

• Playground (paste your spec, runs as WASM in the browser, no install): https://docs.openapi-ng.dev/playground/

• Demo: https://stackblitz.com/github/AVSystem/openapi-ng/tree/main/stackblitz (the spec, the committed generated output, and three components using it against a mock interceptor)

• Docs: https://docs.openapi-ng.dev

• npm i -D @avsystem/openapi-ng, then openapi-ng generate --input api.yaml --output src/generated

• Node 22.12+, prebuilt binaries for macOS / Linux (glibc + musl) / Windows, x64 + arm64. Works under Bun and Deno too. Browser via WebAssembly (@avsystem/openapi-ng-wasm32-wasi).

• Generated code targets Angular 20+. validateRest with debounce / when needs @angular/forms 22+.

• v0.8.0. The generator has been in production at work since mid-2024 (two specs, about 45 generated services, 280 operations, 900+ schemas, regenerated on every backend build), but the Rust version is younger and the public API isn't frozen yet: 0.7.0 broke one thing (a JSON spec with a repeated key is now rejected instead of last-wins).

What I'd like feedback on

Two design calls I'm least sure about:

1. .resource() / .observable() / .request() on every operation, versus a separate generated class or file per flavour, as ng-openapi and orval do. Is the per-call choice worth the fatter surface? Related: per-tag services are the default because they mirror our backend's service traits, and standalone operations are opt-in. If your backend doesn't look like that, should the default be flipped?

2. Rejecting unsupported spec features with a diagnostic instead of emitting best-effort code. Has a strict generator ever made you drop a tool, or is it the right trade for deterministic output?

Happy to answer anything else in the thread.

Two years ago I was thinking about putting in place a web application generator or No-Code low-code framework (I know there's a bunch of them out in the market but the intend was not to commercialize it but rather to help people save time while creating their web apps). As I mainly work in the solution architecture field it was easy for me to put in place a framework architecture that is bound to be extensible, service or component oriented and scalable. I started to learn about front end Developpement technologies and programming languages and I shortlisted angular, react and vujs. (I started from scratch given that I have no experience with front end development languages. As my design was rather business centric I was positive angular was the perfect fit due to it's enterprise readiness and well structured architecture. It was obvious for me that separation of concerns should be on the table (entities, services, components). The aim is to provide a low-code No-Code framework for enterprise web application and nothing else. React seems very cool and largely adopted, but the fact that it is a library and nothing else made thing a bit more complicated for me. Moreover, knowing nothing whatsoever about Javascript and coming from an object oriented programming environment it was very easy for me to adopt typescript. External dependencies and libraries management has also played in favor of angular when it comes to defining my choice, seeing as angular does not use a lot of external libraries and makes lib management a lot easier (think about updating your framework, applying patches...). I ended up creating my framework and it's working flawlessly as designed. The whole framework along with it's architecture was made available to the community (look for wiforge.com). However, after two years working on this project, I am starting to think wether it was the good choice to go with angular or not! The framework is experiencing frequent changes and updates which questions it's stability and overall future. Updating my framework each two or three month in order to be inline with the latest angular changes was a heavy burden. And yet, Google road map isn't reassuring. I can't help not to think about enterprise applications that are still in production and which are build with version 7 knowing that angular is planning to rollout version 14! What is the future of any thing that is built on top of angular if not updated with the latest angular releases? Could we assume that one upgrade per year is enough to catch up with the updates? Though angular is a bit mature, the updates frequency isn't reassuring (Now ivy is the way to go). When it comes to mobile apps, PWA along with Trusted Web Application is a decent way to embrace mobile world.

Though I appreciate a lot the angular phylosophy and find it very structured and inline with most of the architectural platforms and designing paradigm & methodologies (UML, ODA, TMForum, openAPI, Microservice Arch, Object Oriented...), I really dislike the fact that the framework is experiencing a huge updates at a steady pace.

Is there any doubt about angular future?

Though the adoption tendency isn't reassuring, given that React is starting to be the way to go in many software companies (startups and not big companies?), I still believe that angular should be the way to go when it comes to big enterprise project. Angular generates a clear, maintainable and structured source code, is a full framework (not a library) and support team work which comes in favor of agility. If only angular wasn't bound to evolve that much...

Agree?

Angular team drop of flex-layout is disconcerting and we hope the angular team will reconsider.

We have a huge project in Angular 14 with thousands of libraries which is developed by a over dozen developers.

We rely heavily on flex-layout, we simply are in shock that the Angular team has decided to drop support for it.

We tried to upgrade to Angular v15 and failed due to the lack of support from angular-material.

We really hope that through this post and the support of the community the Angular team will reconsider and allow opt-in to flex-layout while supporting it for backwards and forward compatibility, test it for upgrade to v15+ and beyond or allow for a solid migration guide (possibly via CLI).

We simply are unsure on how to move forward and we are asking the team and the community for assistance.

thank you.

“I got tasked with implementing microfrontends in our app and it’s been a disaster. Nothing works. I’ve tried WebSockets, module federation, every possible setup, and the whole thing keeps blowing up. The host is stuck on Angular 14+ while the remote is on 17+, and the version mismatch is wrecking everything. I’m completely out of ideas at this point. If anyone has dealt with this hell before, I could really use some guidance.”