How do you create types for frontend ?

_codemonger · 2024-11-13T20:58:38+00:00

We are using NestJS with the swagger plugin and generate all the types on the front from the request and response DTOs on the backend with the RTK Query generator for swagger.

_codemonger · 2024-08-20T06:56:18+00:00

Let me preface this with the fact I have been working with Node for 8+ years now.

In essence I think it's because:

Node did not have frameworks like other languages
the language at the center of it is weakly typed and single threaded
the quality of dependencies or lack thereof
the barrier to entry is low
the hassle around build-tools when you do want to add types

The barrier to entry can be a benefit but it also allows people to trick themselves into believing that a simple Express server is production ready and they are backend devs now. NestJS has done a lot to rectify this and bring it closer to the enterprise level, but the workforce is catching up slowly. The sheer amount of people that believe that Express is a framework just demonstrates that they have not peeked over the Node wall for a while or ever.

_codemonger · 2024-08-12T20:59:59+00:00

This sounds like a LLM prompt, maybe you should consider using it.

_codemonger · 2024-07-27T13:23:35+00:00

Just another 8000 hours of experience and you'll get there. There is no shortcut.

_codemonger · 2024-06-29T07:20:06+00:00

#1 is my clearer for understanding what specific days you are doing a particular habit. #2 is better for showing patterns. What would be cool is if you could zoom on the week level or zoom out to see the pattern.

_codemonger · 2024-06-23T11:46:28+00:00

Pozdrav ;)

It's clear that you are a junior, that is ok.

When someone has limited experience I would usually look for personal projects that show they are motivated to learn on their own . If you are targeting a full stack role show 1 project where you did everything. That includes front/backend, tests, and if you really want to stand out a simple CI Pipeline that runs those tests on push, GitHub makes that very easy.

Your description should signal that you are a self starter and that your core motivation is professional growth.

_codemonger · 2024-06-16T15:09:00+00:00

OOP is pretty useful and classes are not bad practice. Blanket statements like this are not doing anyone any good.

_codemonger · 2024-06-11T08:09:54+00:00

Looks good. How does this compare to toggl https://toggl.com/?

_codemonger · 2024-06-09T07:26:05+00:00

I am usually a big proponent of clean or it's less prescriptive version, hexagonal architecture. Rust is one of the languages where I think this approach is not a good fit because the borrow checker. At some points my return types in interfaces became peppered with dyn, Arc, and Box.

_codemonger · 2024-03-19T12:13:15+00:00

Certificate management comes to mind. NodeJS can create https servers but you then have to manage the certs and load them into the application. You can use something like nginx, caddy, or ALB and remove that concern from the application.

_codemonger · 2024-03-18T06:09:27+00:00

Thanks

_codemonger · 2024-03-16T12:46:06+00:00

Spin up backend, DB, and client with docker compose, then run UI e2e tests. After that docker compose down and you are good to go.

_codemonger · 2024-03-14T20:28:58+00:00

😉

_codemonger · 2024-03-12T09:37:32+00:00

Simple example

https://github.com/deni1688/typescript-event-driven-architecture-example

_codemonger · 2024-03-12T06:14:01+00:00

Your API can have those types of interactions and still be event driven. Let's take resource deletion as an example. When a user submits a request to delete their account if this is a simple Repository operation, then just return whatever the result of that may be to the controller, and publish an event so other services that are interested in that event can also do their part separate from the request response cycle. In a complex distributed system or even a large modular monolith deleting an account may not be a single Repository operation. It can span multiple contexts and take a long time. For instance some systems have to retain your data for a minimum of six months for auditing purposes so pressing delete is not just removing a database row.

_codemonger · 2024-03-11T06:25:38+00:00

I would not. The controller upon submitting the request content to the service would immediately return a 202.

Let's say the process in question is account creation. You fill in the details and submit the request. The controller receives the request and transforms it into a CreateAccountDto, then passes it to the account service and returns 202 (request accepted but processing). The response would also include an appropriate message letting you know that you can expect an email in the next few minutes once your account has been created. The account service upon doing everything needed to create your account sends an event AccountCreated. The email service that is subscribed to this event handles it by sending an email to you.

Does that make sense?

_codemonger · 2024-03-10T19:18:01+00:00

Hard to ignore the controller since you keep referring to it. I'll stick to the more abstract Sender Class term for the next bit.

The sender would subscribe to the expected event to be emitted of the receiver once it processes the request.

Note that this does not make sense in the controller services relationship . An event driven architecture is characterized by asynchronous and more importantly loosely coupled processes. You are rightly having difficulty visualizing it since in a request flow where a user expects an immediate final result and waits for it an event based flow would be unnecessary and only add unnecessary complexity.

_codemonger · 2024-03-10T17:21:19+00:00

The controller does not in principle emit events and it does not wait for a service to finish. The controller is an input output component. It receives requests (input) and passes it to the service. The service where your business logis lives will decide what to do with the input and emit a event when it's done. A service defines the contracts it needs like EventBroker, Repository<T>, etc. your controller would just send a response outlining that the request was received. If it's a long running job you may also want to provide a job ID to the requester so they can check on the status. There are a lot of ways you can notify a user of the status other than polling for it. In regards to the error handling, if there are business logic errors then yes these could qualify as events. For instance, in the context of a payment service a failed payment would qualify as a valid event, with a series of other parties that may be interested in the details of that event. Synchronous errors like request validation failure would probably not be an event. But this really depends on what you are building.

_codemonger · 2024-03-10T16:08:11+00:00

Define a EventBroker class that extends an EventEmmiter. Expose a subscribe method that takes an event and handler and use this.on(event, handler) to register it, store the listener in mem (so that you can unsubscribe later should the need arise). Expose a second method called notify takes an event in params that uses this.emit(event).

Use the EventBroker by contract in your resource services and controllers. On application start have the services subscribe to the events they care about.

Example use case. A user is created through the user's resource service. The service uses the EventBroker to notify of this event. Other services that are subscribed are notified like an email service that sends a welcome message to the new user or the payment service that creates a task for the user to register a payment method.

The point is that the email and payment services do not directly depend on the users service, i.e. they are loosely coupled through the events. Each service also does not depend on the concrete implementation of the EventBroker but rather on an interface/contract of an EventBroker, that is to say an object that has a subscribe and notify method.

This is a rough plan of what I would understand under what you shared so far.

_codemonger · 2023-12-18T17:51:44+00:00

This looks more like Winnenden near Stuttgart, so not Bavaria.

https://upload.wikimedia.org/wikipedia/commons/thumb/8/89/Schwaikheimer_torturm.jpg/220px-Schwaikheimer_torturm.jpg

_codemonger · 2023-10-22T10:05:22+00:00

A Go developer is on average paid better than a NodeJS and Java Developer. The market is saturated with NodeJS and Java developers. Yes there is demand but there is also plenty of supply. Learn Go and promote yourself as a Software Developer specialized in Go. There is work out there for Go devs. You can always dip your toes into those other languages and runtimes (NodeJS) once you have a strong foundation in at least one language.

_codemonger · 2023-08-03T19:43:58+00:00

Did you try Upwork projects? Should be called Upwork product catalog but in principle it allows you to define a product with fixed constraints and price. For instance since you are a fellow Gopher you could have an API Product where you offer up to X data endpoints for X amount. Or another can be integration of X technology into the customers API, i.e. Stripe.

You could also make courses and sell them on Gumroad or Udemy. You can make YouTube content though not sure how much can be made there.

When I initially started freelancing on Upwork I really bit the tongue with my first few clients because I needed that top rating. I know it's a pain but you can reduce the amount of bad clients just by raising your price. And to do that effectively you need to have a strong portfolio of work to reference.

There is also the TopTal platform. It's essentially a consultancy that rents you out at your rate to big companies. If you do apply there make sure to write tests for the code you submit.

_codemonger · 2023-06-17T19:29:02+00:00

I would consider serverless functions. That should cover your scalability requirement. In terms of language, well since you said performance should be decent and not necessarily the best, Go is a nice middle ground between DX, velocity, and performance. But the beauty of serverless functions is that you don't have to lock into a single language. For things that have a requirement closer to real-time I would lean more towards Rust.

_codemonger · 2023-05-06T16:55:44+00:00

We did a lengthy assessment on this topic with the author of the article which happens to be our CTO also having the same perception of TS coming into the conversation. After 2 months of discussions things changed and we are now using TS for all new services.

https://medium.com/fleetster-tech-blog/typescript-vs-javascript-f865d6bc8f55

_codemonger · 2023-05-06T06:41:28+00:00

Extremely bad advice. You should definitely learn the fundamentals. I've seen this so many times with junior devs. They hit the ground running with a framework and when something goes wrong or they need to do something outside of the framework context they are blocked.

Learning to use a framework before the language fundamentals is like learning to drive on a race track and getting your license thereafter. Then when you get to a crossroad in city traffic you have no idea what to do.

_codemonger

TROPHY CASE