DEV Community: Jedidiah Weller 👑

How We Cut 80 % of Our Backend Calls in Summon Worlds

Jedidiah Weller 👑 — Fri, 01 Aug 2025 17:40:00 +0000

TL;DR

Reduce redundant API calls by centralizing loading logic in a shared helper.
Always expose a domain model (class instance) instead of raw state slices.
Cache with shareReplay so multiple subscribers share one request.
Dispatch only plain-object payloads—no class instances in actions.
Inspired by our experience in the Summon Worlds AI world-building app.

0. The Backstory 🏗️

First things first - a story. In September of last year, we took over an AI World Building App called Summon Worlds. The app was a cool idea, had an great community, and scratched that gaming itch that all developers have.

So after we took it on, we rebuilt the (very hacky) flutter prototype in Ionic + Angular, and we decided to use NGRX to help with performance and storage calls. Since we were in a hurry, that was about all the thought we put into the pattern in which we were implementing NGRX and we thought it would be an easy process.

It was not.

So, fast forward till today - there were a ton of architecture and pattern decisions that I wish we did differently, and I'd like to share some of them with you so that hopefully you do not make the same mistakes as we did.

This particular article is focused on an "accidental" antipattern of NGRX + Clone Deep that caused major issues. If you like it let me know, and I'll write a couple more about some other anti-patterns to avoid!

1. How We Discovered The Antipattern 🏗️

The State was managed via NgRx and persisted to Firebase. One morning we noticed our billing spike—and Cloud Functions logs revealed that loading our simple “feed” screen fired 42 loadEntity calls every time. On slower networks, users waited ages. We knew something had to change.

2. Recognizing the Anti-Pattern

2.1 The Over-eager Helper

A common helper service looked like this:

@Injectable({ providedIn: 'root' })
export class GenericHelperService {
  constructor(private store: Store<AppState>) {}

  // Raw state slice used everywhere
  getEntityState$(): Observable<EntityState> {
    return this.store.select(selectEntityState);
  }

  // Lightweight shortcut mapping to a class
  getEntity$(): Observable<EntityModel> {
    return this.store.select(selectEntityData).pipe(
      map(data => new EntityModel(data))
    );
  }

  // Dispatching class instances directly
  updateEntity(model: EntityModel) {
    this.store.dispatch(updateEntity({ payload: model }));
  }
}

Every component calling getEntity$() would dispatch loadEntity again and again, re-instantiate the model, and violate NgRx’s serialization rules.

3. Core Principles of the Fix

Raw slice only for edge cases.
Instantiate your domain model exactly once in a shared helper.
Dispatch only plain JSON payloads—no class instances in actions.

These principles rescued our performance in Summon Worlds and will help any NgRx project.

4. A Generic Refactor Recipe

4.1 Strengthen the Helper

@Injectable({ providedIn: 'root' })
export class GenericHelperService {
  constructor(private store: Store<AppState>) {}

  /** Raw slice — cache and reuse sparingly */
  getEntityState$(): Observable<EntityState> {
    return this.store.select(selectEntityState).pipe(
      shareReplay(1)
    );
  }

  /** Central loader + model emitter */
  getEntity$(id: string): Observable<EntityModel> {
    // Trigger load exactly once per id
    this.store.dispatch(loadEntity({ id }));

    return combineLatest([
      this.store.select(selectEntityById(id)),
      this.store.select(selectEntityLoading(id))
    ]).pipe(
      filter(([data, loading]) => !!data && !loading),
      map(([data]) => new EntityModel(data)),
      shareReplay({ bufferSize: 1, refCount: true })
    );
  }

  /** Mutations accept model, dispatch plain data */
  saveChanges(model: EntityModel): void {
    const payload = model.toPlainObject();
    this.store.dispatch(updateEntity({ payload }));
  }
}

shareReplay(1) shares one subscription, caching the latest value.
combineLatest + filter waits until data is ready before emitting.
toPlainObject() strips methods, leaving a serializable payload.

4.2 Use the Async Pipe Everywhere

Before (Summon Worlds style):

ngOnInit() {
  this.sub = this.helper.getEntity$(id)
    .subscribe(model => this.value = model.compute());
}
ngOnDestroy() { this.sub.unsubscribe(); }

After:

value$ = this.helper.getEntity$(id).pipe(
  map(model => model.compute())
);

<div>{{ value$ | async }}</div>

No manual subscriptions, no memory leaks, no boilerplate.

4.3 Remove Deep-Clone Workarounds

Swap out:

const safeData = cloneDeep(rawData)!;

For:

computed$ = this.helper.getEntity$(id).pipe(
  map(model => model.optionalProp ?? defaultValue)
);

TypeScript strict checks catch missing properties, eliminating the cloneDeep band-aid.

4.4 Centralize Error Handling

Instead of catching errors in every component:

this.helper.getEntity$(id).pipe(
  catchError(err => {
    console.error(err);
    return of(null);
  })
);

Handle failures in an effect:

loadEntityFailure$ = createEffect(() =>
  this.actions$.pipe(
    ofType(loadEntityFailure),
    tap(({ error }) => this.toast.error(`Load failed: ${error}`))
  ), { dispatch: false }
);

Your components only worry about rendering the happy path.

5. Migration Checklist

Helper overhaul

Add shareReplay on raw-slice methods.
Implement getEntity$() with load dispatch, combineLatest, filter, mapping, and shareReplay.
1. Component cleanup
Replace manual subscriptions with async-pipe streams.
1. Payload serialization
Add .toPlainObject() to your models.
Dispatch only JSON in actions.
1. Remove cloneDeep
Delete all deep-clone code.
1. Centralize error flow
Catch errors in effects only.
1. Enable runtime checks

   StoreModule.forRoot(reducers, {
     runtimeChecks: {
       strictStateImmutability: true,
       strictActionImmutability: true,
     }
   })

6. Measuring Success

Metric	Before	After	Improvement
Backend calls per view	42	4	−90%
Memory on initial render (MB)	28	18	−36%
Time to first paint (s)	4.2	2.7	−1.5

(These are some of the actual numbers we achieved, fyi)

7. FAQs

Q: Why not dispatch class instances?
A: They break DevTools serialization, effect replay, and cross-tab sync. POJOs are the safest contract.

Q: Aren’t selectors memoized?
A: Yes—but extra loadEntity dispatches before data arrives bypass selector caching. shareReplay fixes that gap.

8. Generic Snippets to Copy

Model Skeleton

export class EntityModel {
  constructor(private data: EntityData) {}
  get id(): string { return this.data.id; }
  compute(): number { /* domain logic */ return 0; }
  toPlainObject(): EntityData { return { ...this.data }; }
}

Helper Skeleton

@Injectable({ providedIn: 'root' })
export class GenericHelperService {
  constructor(private store: Store<AppState>) {}
  getEntity$(id: string): Observable<EntityModel> {
    this.store.dispatch(loadEntity({ id }));
    return combineLatest([
      this.store.select(selectEntityById(id)),
      this.store.select(selectEntityLoading(id))
    ]).pipe(
      filter(([data, loading]) => !!data && !loading),
      map(([data]) => new EntityModel(data)),
      shareReplay({ bufferSize: 1, refCount: true })
    );
  }
}

9. Next Steps

Measure your own before/after metrics.
Refactor one entity at a time.
Share this guide and (of course) check out Summon Worlds if you are into AI world-building.

Happy refactoring—and may your selectors be ever memoized!

What to Do After the Coding Academy

Jedidiah Weller 👑 — Wed, 19 Dec 2018 20:46:34 +0000

Introduction - What to Do After The Coding Academy
Step 1 - Learn The True Fundamentals
Step 2 - Create a very simple C++ application
Step 3 - Translate that C++ Application into a Web Application
Step 4 - Understand the Internet
Step 5 - Understand your environment
Step 6 - Go HAM on a Web Dev Framework - but be well-rounded too
Step 7 - Practice Being Systematic
Closing Remarks

What to Do After The Coding Academy

Hello everyone! For about 5 years now I've owned and operated a development shop, and in that time I have had the privilege of seeing many developers grow their skills (both professionally and personally) as they entered the workplace. However; I quickly noticed some trends from individuals coming from Coding Academies and Bootcamps.

While teaching our young padawans, I quickly learned that there is a lot of information missing from most Coding Academy curriculums. I chalk it up to the programs being so short and attempting to cram so much knowledge into their brains at a time. Most people gain the knowledge of "what is" software development, but lack the wisdom of "how to" use it.

If this is you (or one of your team members) - you're not alone. It's nearly impossible to become a full-fledged software engineer in 3-6 months, although places like NYDCA would like you to believe otherwise. And perhaps that is why they shut down. But fear not; there is hope! Coding Academies are a great start to your journey so long as they are followed by the right mentorship and guidance on where to go next.

So, I'd like to provide exactly that - mentorship and guidance on "What to do next". I hope this article will graduates, as well as Senior Devs and Managers out there tasked with training them. We're all in this career together, so let's help each other make it an amazing one for everyone.

P.S. If anyone has additional items you think are useful; I'll update this article to be a culmination of best practices/wisdom.

Step 1 - Learn The True Fundamentals

You may have thought you learned the fundamentals at your coding academy; but alas you actually learned the fundamentals of web development. What you did not yet learn is the fundamentals of the "how" and "why" of computer science. Questions like "What is an IP address?", "What is a var (under the hood)?", and "How can I step-through debug this problem?" are never asked nor taught, so it's up to us to fix that.

To get this understanding I'd recommend traveling to the past so that you can understand the future. Scripting languages are NOT the place to learn fundamentals; however, C++ is built on the fundamentals. You'll probably never use this language again - but I DO want you to take 2-3 days to go through the following tutorials. I promise they'll be beneficial - so here's the steps

Download Visual Studio Code
Take yourself through this C++ tutorial
Complete chapters 0, 1, 2, 4, 5, 6, 7:
While completing the Chapters answer the following questions:
- What did you learn from this chapter?
- What questions/difficulties did you have during the chapter?
- What questions or things do you want to try, at the end of the chapter?

Step 2 - Create a very simple C++ application.

I'd recommend the following:

Create an application that

When launched via the command line, says "Hello, what would you like to create? "1: A Dog", "2: A Cat""
When the user types "1" and hits enter, a Dog class is created.
In the Dog Class Constructor, have a print function "I am a dog, I am born"
In the Cat Class Constructor, have a print function "I am a cat, I am born!"
Abstract Dog and Cat class to be part of an Animal class, and inherit from it.
Complete some other small changes to reflect what you've just learned in your tutorials

Step 3 - Translate that C++ Application into a Web Application.

Now, create a Web Application using the technology you've been taught at your coding academy - but instead of the command line, have a GUI through a web browser. Either an Angular Application or a Rails Application will do just fine, then answer the following questions:

How does C++ compare to javascript/ruby?
What are the differences?
Which parts were easier? Which parts were harder?
Have a friend introduce an error in both - but not show you where. Now, try to debug the error on both. Do you see a difference in debugging?

Step 4 - Understand the Internet.

Most people don't understand what the internet actually is; and it's truly magic.
Did you know there is all this hidden data in every packet that's sent over the web? Do you know how your ISP works? Well, to get started let's read this Stanford whitepaper on what the Internet actually is.

Step 5 - Understand your environment.

This step is a controversial step and is best done on an old crappy computer you don't use anymore. If you don't have one - make sure to back everything up on your current system.

(Assuming you're creating an Angular App) Download and install Homebrew, Node, NPM, Bower, and Grunt.
Try to install and run A MEAN Stack sample app
Uninstall the current version of node, and install an older version. Play with versioning through NVM
Try to run the same app.
Now, do the same thing on someone else's computer. Doesn't matter what type - there's learning on all OS :)

You may or may not have issues - guess what; version dependencies are a BIG BIG challenge for a lot of developers. 5 people with macs may all have different environments - and that's not even including all the variations of Windows / Windows + Ubuntu / Linux distros.

(Bonus) Wipe your computer - and re-install everything. That's the controversial part, but often when you're doing development and you don't quite understand filepaths and chmod/sudo consequences you'll mess up your dev environment. You can spend hours debugging it, or you can wipe and restart - your choice.

Now, you must be thinking to yourself "There's got to be a way to standardize environments". Yes, there are plenty of ways. A well-known approach is a tool called Docker. I'll let you read up on the rest.

Step 6 - Go HAM on a Web Dev Framework - but be well-rounded too

I personally love the Angular + Ionic combination for Web & Mobile apps, but there are a ton out there. React.js is awesome and I'll be at the Vue.js conference in Amsterdam in February. Once our interns at OpenForge are done with the above steps (and some 1-1 sessions), we ask them to start completing some online courses through Udemy.

First, I'd take a quick debugging class here to learn about Chrome dev tools
Second, complete the entirety of this Angular 7 course. It covers a LOT
Third, take appreciation for my array numbering to the left <-- If you know your basics, you know why I did this :)
Fourth, practice creating a MEAN stack app and deploying it. Here's some links
http://www.hongkiat.com/blog/node-js-server-side-javascript/
https://devcenter.heroku.com/articles/mean-apps-restful-api
http://blog.modulus.io/build-your-first-http-server-in-nodejs

Step 7 - Practice Being Systematic

PAY ATTENTION TO THIS - This is the most important piece of advice I can give you.

When you're working on a feature, debugging, or any type of development - commit after every meaningful change. Do NOT wait for the feature/bug to be finished.

Computer Science is a science, and science is systematic. We try, measure, and come to conclusions. I promise you that if you break down large commits and large problems into super small ones; you will accomplish tasks 10x quicker and be happier for it.

Closing Remarks

I hope this is helpful - it's been the 'time-tested mother-approved' formula for us for a couple years now.

If anyone has anything else to add (or recommends modifications) I am all ears, please comment below!

Best Regards,
www.twitter.com/jedihacks

Passion Projects are Fun - Except In Production

Jedidiah Weller 👑 — Sun, 25 Nov 2018 15:45:55 +0000

Right around the time that the Ionic team came out with Stencil.js our company made a brand transition from Webjunto to OpenForge. Since we are all massively in love with all things technology; we said "OMG - An opportunity to play with Stencil! Let's build our Website using Stencil as a web-component pre-compiler and scratch that Wordpress B.S. It will be so much faster!".

From a business owner's perspective, it was a perfect opportunity to transition from Wordpress to something that we built with our own hands. We could Open Source and talk about it. It allowed us to train our team on a new technology while simultaneously applying it to something useful.

But - we were unprepared. That's when the pain hit.

Our Assumption

We drastically underestimated how much is truly built into Wordpress that we never think about. Between Blog, Page, User Management, and SEO capabilities - it's a huge set of features, and eliminates a lot of need for process internally in the team between the design, dev, and business departments.

We also assumed that anything that was in Wordpress we could easily build, and to our team's credit we can build the features; however - what we don't have is the process for identifying what needs to be reviewed across departments.

For instance; how many business people think about the manifest.json file? How many people (in a full design & dev team) are qualified to identify SEO mismatches between content and url routing? These things are automatically provided and identified by Wordpress and Yoast, and we didn't even realize it.

The benefit was that it created a need to more tightly integrate the 3 major departments at our company (Design, Dev, Business); however, the down side was that we had to create a process for this and we were completely unprepared.

My Advice

Was it worth it? I think so due to the training to the team, PWA expertise, and lessons learned; however, on a scale of 'how worth it' it was not as clearly a win as I expected.

I'll break down my advice into a bulleted list of what was worth it, and what pieces we missed. My hope is if you would like to try the same thing for your company, you'll have a bit of a headstart on what troubles may arise.

Worth It

The experience & training (as we move into single-source PWA's)
The speed (It feels like the road-runner compared to WP)
The control (fully customizable, without any plugin development)

Harder Than Expected / Unexpected

SEO Management. What's the replacement for Yoast?
- Robots.txt
- Manifest File
- URL Routing Strategy (and who reviews this?)
- 404 Page for old I.E. (we just redirect)
- Canonical Links
- Alt Text to images (we keep forgetting - need to update process)
Polyfills
Lighthouse Optimizations (local vs. deployed)
Smooth Scrolling
Accessibility

There were some more items that didn't make it into our changelog, as I think of them I'll update the post.

Hope this helps folks!

~Jedi

Tutorial 1,000 - A Real Production App

Jedidiah Weller 👑 — Wed, 24 Oct 2018 14:25:42 +0000

Hey everyone,

Yesterday we released (and open-sourced) a full production mobile app, and wrote a guest blog about it through Ionic's Blog. It's not everyday we get to see the 'nuts-and-bolts' of a full app, so I figured I'd share it with the community here as well :)

It took around 400 hours to design and build the Ionic 3 app. We used a serverless architecture, Firebase, and Ionic 3.

Why we built it

We're developers - although we always scope work the scoping process can get messy.

It's very easy to be 'peer pressured' (even unknowingly) into changing your estimates when your friends and colleagues think differently. This is exacerbated when you have junior and senior developers in the same room providing estimates together. The junior devs are often afraid to provide real estimates, because they are much longer than the senior's.

We used to use planningpoker.com for scoping sessions; but everyone could see each others estimates and then during a session team members would change their answers to avoid confrontation. This often leads to inaccurate scopes; because the person who's answer wins is not always the person tasked with completing the work.

Why we open-sourced it

It's aggravatingly difficult to find examples of real production applications that are open sourced (but still simple to follow). When I train new team members, I find that going from Angular's "tutorial 101" to building a full application is about a 10 foot step, and no one has 10 foot legs.

So, when the dev team proposed designing and building this tool we agreed to open source it and write about it. It's got some cool features, such as

Teamwork Projects integration
Serverless architecture
Ionic 3 application
Live scoping via Firebase
Firebase. Firebase. Firebase. We're loving Firebase :D

We wrote a full guest blog post about the architecture and decisions we made on Ionic's Blog, so rather than re-invent the wheel I'd encourage everyone to read the full breakdown there.

Should you download it?

No - you should Clone it from Github and use it yourself. However; we figured it may be hard to get some project managers on board if it didn't have a least a semblance of an established app. So go ahead, use it if you'd like, but seriously - feel free to take it as well :)

Next Steps

We had a lot of positive feedback from the product; so we'll be releasing another full production app next month (open sourced) and blogging about the process. We don't intend to build any more integrations besides Teamwork because that's what we use internally at OpenForge.io; however, if you are using another tool and would like to create a PR we'd be happy to help support it.

Thanks everyone, stay cool and dev on!

Jedi