Hey guys, have a general question of how you guys build your websites… I have a React + Typescript frontend app, living in a repository. Then I have a backend app, living in another repository, built with NestJS + Typescript. This backend app it’s a REST API built for the frontend, in a “BFF style”. My goal…. I want to share the TYPES between both applications, due most of them has to be repeated in the consumer and the producer. I been thinking in 4 different alternatives to share those types: 1. Build a third repository, which would be like

@types/mycompany

and put it as a

devDependency

on both projects. 2. Put the backend project as a

devDependency

of the frontend project. 3. Use an “API client generator” like swagger/OpenApi or something similar that can auto-generate types. I don’t know much how to share the types here yet, but it’s a theory. 4. Use a mono-repo strategy… I don’t like this due my company already uses separated repos for each app. What should I do? anybody else doing any of these?

Option 1 could be okay if your types are pretty stable and/or you have a good way to publish/subscribe to updates. Otherwise, this can become burdensome. Option 2 is a little better if the types are evolving fast. I have a colleague who is interested in something like option 3, but it's always seemed to me like probably too much overhead. 4, lots of people will say do it anyway, but if it's not your way, then don't.

Yeah at the moment we are doing copy/paste, maybe option 2 could be intermediate solution.

Whenever I make an expedient compromise, I try to write down why in a code comment so somebody in the future can say "well, I'm not willing to make that compromise!" and change it.

1. on the back-end put

koa

in your lambdas and do your routing through that (and

serverless-http

to use

koa

with lambdas) 2. also on the back-end use

tsoa

to generate a swagger based on your controllers 3. on the front-end use

nswag

to generate your api client and types based on the swagger

@João Pedro thanks, going to check it.

I went with option 1, and there have been no downsides, other than having to update

peerDependencies

a lot.

Interesting.

This option feels similar to me as when people are using 2 separate languages and generate the frontend from the backend.

I didn’t get your last sentence.

say you have a database model library, it calls your database and presents the item. It is installed in the API, as well as a cron job deployment. In this case it would actually be the model lib you would install in the frontend, rather than installing the backend. You would also install this model lib in OTHER backends who call the API of this domain.

Oh yeah.

that sounds like Option 1, just installed using a monorepo instead of multiple.

Yeah.

that doesnt violate anything, you are only sharing interfaces, not the logic

My concern is how to do this with multi-repo, in other company we have like 50 repos.

its basically the same as mono or multiple, you just install an npm package either way.

Yeah.

if you REALLY want some kind of automatic check across your entire stack, you could implement some kind of minimum version GitHub action or something.