https://serverless-stack.com/ logo
#help
Title
# help
a

Adrián Mouly

12/20/2021, 11:30 PM
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?
m

Matt Morgan

12/20/2021, 11:52 PM
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.
A little copy-pasta while things are getting rolling and you validate the approach isn't the worst thing in the world.
a

Adrián Mouly

12/20/2021, 11:53 PM
Yeah at the moment we are doing copy/paste, maybe option 2 could be intermediate solution.
m

Matt Morgan

12/20/2021, 11:54 PM
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.
j

João Pedro

12/21/2021, 2:14 AM
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
a

Adrián Mouly

12/21/2021, 2:23 PM
@João Pedro thanks, going to check it.
d

Derek Kershner

12/21/2021, 4:56 PM
I went with option 1, and there have been no downsides, other than having to update
peerDependencies
a lot.
a

Adrián Mouly

12/21/2021, 4:56 PM
Interesting.
How you do that? Doing npm install?
d

Derek Kershner

12/21/2021, 4:56 PM
This option feels similar to me as when people are using 2 separate languages and generate the frontend from the backend.
npm i
,
npm update
, just like any other package.
Your option 3 can actually still use option 1 as well, fitting the auto-generated interface to the one in the lib will check they are correct.
I wouldnt recommend some kind of cross repo auto generation, too many possibilities for error.
Option 2 doesnt scale well. We are at several domains and 60-70 repos and we would be installing 1-3 backends for each frontend.
we would also be doing things like installing backends in libs
a

Adrián Mouly

12/21/2021, 5:16 PM
I didn’t get your last sentence.
d

Derek Kershner

12/21/2021, 5:20 PM
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.
could get messy fast, and it also violates some principles of microservices.
a

Adrián Mouly

12/21/2021, 5:20 PM
Oh yeah.
Yeah we do that in other company, with mono-repo.
But yes, that violates the MS principles.
We faced that issue many times, but decided to not use strict meaning of microservices.
So we have a common
data
package in the mono-repo.
And we use it from many different lambdas.
Microservices are frustrating sometimes, haha.
d

Derek Kershner

12/21/2021, 5:22 PM
that sounds like Option 1, just installed using a monorepo instead of multiple.
a

Adrián Mouly

12/21/2021, 5:22 PM
Yeah.
Well I did mono-repo for other company that I’m working on, we have backend + infra all into 1 repo…
d

Derek Kershner

12/21/2021, 5:23 PM
that doesnt violate anything, you are only sharing interfaces, not the logic
a

Adrián Mouly

12/21/2021, 5:23 PM
My concern is how to do this with multi-repo, in other company we have like 50 repos.
Yeah.
If we share the interfaces, yes.
d

Derek Kershner

12/21/2021, 5:23 PM
its basically the same as mono or multiple, you just install an npm package either way.
a

Adrián Mouly

12/21/2021, 5:24 PM
Yeah.
d

Derek Kershner

12/21/2021, 5:24 PM
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.
but frankly, that would only matter in the case of breaking changes, which you should avoid anyway for obvious reasons.
3 Views