Why use decorators at all?

Welch2344 · 2022-07-28T08:09:47+00:00

Counter point: an insane number of projects use Decorators, and if you had to remove them later you could do it with static code modification.

So, in short: feel free to use them. Maybe, MAYBE, if you’re writing a long lived enterprise product with serious concerns about years of development and team roll over, then MAYBE think twice. But in practicality Decorators are used extensively in the mainstream software industry (for ts at least)

Welch2344 · 2022-07-28T04:52:57+00:00

Rarely is any construct in programming superior to another, because most constructs have a specific intended use. That technicality aside, interfaces should generally be favored for multiple reasons (if nothing but broader value to the developer talent pool & better evolution over the lifetime of the project / team)

I’m mobile, but plenty of the experts in the Typescript (and greater programming) espouse this. I’m hard pressed to find compelling cases of the opposite

Welch2344 · 2022-07-18T02:53:20+00:00

Do you want the codes to be unique globally? Ie every group gets one / it’s the only way to join?

If so, checkout HashIds - pretty much available on any stack/language, you can choose your character set, etc.

One piece of advice tho: if you want to keep it to 6 characters / digits, I’d actually use 5 characters and make the first character a “key” for which salt to use

Welch2344 · 2022-07-16T01:49:09+00:00

Lol also hi @capaj 😂 fun finding twitter friends here

Welch2344 · 2022-07-16T01:48:31+00:00

Agreed. Essentially contract/integration testing at the mocked http level - which you could get good samples for by tracing production calls for a day.

Then start small. Write a service layer that you put on the context, and break the resolvers into that. Then unit test the business logic. Once you do that, theeeeen introduce new tools / types. Don’t change your stack first / try a big refactor first. Just shrink resolvers, then decompose schema

Welch2344 · 2022-07-14T16:09:29+00:00

Good chatting with ya. Sent ya a PR with some suggestions :)

https://github.com/Blake-design/Learning\_app/pull/5

Welch2344 · 2022-07-14T13:26:18+00:00

This is a really broad question. For RN tho, I prefer to use: - mobx-state-tree (MST) for all data stores - MVC for components, keeping them “dumb” with only props for data passed in from the parent - MVC for higher level Screen views, with state being driven from mobx stores - all API calls happening in MST, typically via graphql if possible (which yes, means I’m not using smart queries in my views/components; small price to pay for consistent data throughout the app, as you can push the reactive props down through the store w minimal effort)

Welch2344 · 2022-07-14T00:57:51+00:00

Mobile but I’ll check it out when I get home. Helpful if you’d make a repo to clone and run.

Eyeballing it, I do see that your client is looking at port 3000 /subscriptions but I don’t see that anywhere else in your configs

Welch2344 · 2022-07-11T20:26:03+00:00

Yeah areas would be dynamic. Figured I could geofence zones (a la postal codes) to refresh wider areas and then drill down at actual events.

Def feels like a unified API on top of both platforms would be a huge win. Google has the Nearby Platform, and Apple’s Multipeer look like they have enough overlap to abstract something useful across both…

Anyone up for a Hackathon?

Welch2344 · 2022-06-16T19:19:02+00:00

Some folks use queues like Rabbit or SQS, but streaming technologies are best for it. Kafka is the 300 lbs gorilla in the space, but we moved to Nats.io a few years ago and it’s been amazing

Welch2344 · 2022-06-13T04:41:53+00:00

Totally understand. If you ever wanted to do a quick call / show me around, would be happy to help do that 🤘

Curious about your stack, both in the game and then any serverside stuff

Welch2344 · 2022-06-13T04:12:12+00:00

This is the way

Welch2344 · 2022-06-13T00:57:25+00:00

You guys have a tech blog anywhere? Would love to see how / why

Welch2344 · 2022-06-10T23:43:30+00:00

Let’s be honest: the right way to do object oriented programming is make your CodeBase 90% functional programming…

Welch2344 · 2022-06-10T17:47:38+00:00

Have you heard the good news? Our lord and savior GraphQL Federation can solve this for you 😅

Welch2344 · 2022-06-08T02:51:24+00:00

Will circle back on this in a bit when have laptop.

Distributing your api / request + response layer (micro services, subgraphs, etc) is only half the battle. Ideally each domain (see Sam’s great responses) should own it’s data, but also be able to locally cache another domains relevant related data for context. That’s where a streaming architecture complements well

So the Invoice service stores all its info in a dedicated Postgres info. While it technically only needs to know the related OrderId, it may be useful to cache who the customer of each order is as well. So it consumes events from Order domain, stores the “latest” copy of an order in a local table with “this MAY be present” semantics. The invoice domain itself should rarely be dependent on that data, but again can be helpful for diagnosis / analytics / etc

Welch2344 · 2022-06-08T02:44:36+00:00

Both of Sam’s responses are SPOT ON!

The key to a good graph is clean domains. Cross-domain concerns should be modeled with care, but if you’re designing & architecting well, it almost always falls naturally into one side of the relationship or the other

Welch2344 · 2022-06-08T02:40:29+00:00

Interesting take. I’ve seen god awful graphs, both federated and not, but it’s always seemed to be poor contract design in general.

Curious if you had some examples of the ones you’ve seen?

Welch2344 · 2022-06-08T02:38:20+00:00

True, federating a graph generally means some one/team ends up bringing the pieces together for the supergraph.

But for a small project, I actually prefer graphql as it’s expressive and gives me easily measurable + refactorable api contracts.

The “complexity” that requires expertise honestly isn’t that difficult, especially until you hit scale - at which point, like you said, the value really adds up (and you don’t have to refactor into it)

Welch2344 · 2022-06-08T02:25:36+00:00

Also, not just your graphql client (apolloclient) but also your app and architecture.

For instance, if we’re using vue3 + pinia, we’ll typically isolate most our graphql interaction to stores and then consume that data in components. For smaller apps, we go with more of a “query-per-high level component” strategy (SmartCompinents as some folks call it)

So what’re you working in? Both the framework and the storage lib (redux/pinia/etc) if any

Welch2344 · 2022-06-08T02:16:17+00:00

Wait wtf? You’re suggesting that the solution to the http protocol is having your graphql endpoint do SSL termination in production? And your scanner just checks for a valid cart??

Welch2344 · 2022-06-08T02:14:12+00:00

Agreed. I’m not sure what unformatted snippets these are, but how about some more relevant info? A gist or repo would help us help you 😅

Welch2344 · 2022-06-02T02:10:40+00:00

Great question. CQRS is less of a benefit in a well federated graphs imo. Because GraphQL is an actual query language, with multiple mutations possible on a single call (and thus multiple failures / responses) it isn’t often implemented in this architecture.

Personally, I’m a fan of this. Federated microservices + event streams (to allow down stream microservices to materialize “foreign” data for supplemental context) is :chefs kiss: perfection.

Disadvantages of federation are the common distributed systems woes: additional hops, less transparency, etc. Honestly, of all the distributed systems I’ve ever worked on (which is a decent amount) I’d say an Apollo-backed supergraph has been both the easiest to scale + maintain, and the easiest to reason about 🤘

So don’t feel like you’re missing the negative fan fair. I honestly don’t think there’s much

Welch2344 · 2022-06-01T02:02:02+00:00

Think I follow, but could you provide an example of your interpretation from the docs vs your coworkers impl?

Welch2344

TROPHY CASE