Comment by wruza | Hacker News Reader

Comment by wruza | Hacker News Reader

Parent Full thread

Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border.

Thankfully, Node and browsers slowly converge, so isomorphic code is less and less of an issue.

Btw, how does HN develop solo-dev apps? Do you switch between two projects? Run two separate webpack configs simultaneously? How do you share code/typedefs/dtos between them? Do you use or want to use backend HMR? Backend webpack-like import extensions?

got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works

When I finally built my perfect set of webpack configs, I deleted them after a couple of months. This complexity is “fun” to set up, but maintaining it is not something I want not working as a “devops” full time. Achievement unlocked, so to the trash it goes.

> I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command

I did create a proof of concept how this could be done in parcel https://github.com/mochicode/parcel-fullstack-poc.

The /src folder contains:

1. /api => backend

2. /app => react frontend

3. /shared => shared code

Once everything is installed, just run "npm start" and it will:

1. build and watch your src folder

2. react hmr/fast-refresh works

3. nodemon will reload your node server when things change

4. serve your react app on localhost:8000/frontend, currently hard coded, but I could also load this from the package.json file.

Not zero-config, but it almost gets you there.

You can cut down the duplicate config with webpack-merge package. I start with a common config object that defines loaders, aliases, etc. and it gets imported by my frontend/backend/cronjob/worker targets that simply describe the entry/outputs

I also recommend installing ts-node and writing your configs in Typescript to avoid typos

Here's an old side project of mine that has 3 targets [1]. I personally don't think it's that complex but it does have hundreds of lines altogether.

[1] https://github.com/Trinovantes/MAL-Cover-CSS/tree/master/bui...

I use Next.js, which does both front and backend in one command. It may not be powerful enough if you need truly large API’s, but for anything I build it’s more than enough.

Rust :)

https://m.youtube.com/watch?v=oCiGjrpGk4A

but more importantly, I recommend embracing the frontend-backend separation. it's important in desktop contexts too. after all, you don't want to block the UI thread with waiting for I/O, right?

of course the last ~2 decades were about coming up with various hacks, workarounds, solutions to make the whole threshold easier to pass (from Java applets to Ajax/XHR, comet/long-poll, websockets, server sent events, localstorage, WebSQL, WASM, service workers, and so on), but the basic architectural separation of concerns remains.

...

regarding sharing things between frontend and backend: OpenAPI + openapi-generator; monorepo works okay in VSCode, etc.

many people opt for RoR-like frameworks where they don't have to write frontend JS if they can avoid it (see also htmx)

I think your comment is mixing two kinds of separation together: process/thread separation and project separation. To me, a project is a single concern, monorepo or not, and dividing it along a particular api border seems unnatural.

Anyway, I’m looking for a tool that could make this part of development simpler by joining all these efforts in a “project and process manager” way instead of maintaining multiple toolkits/configs or generators. The latter I know how to do. Been there, done that, fed up.

> [...], and dividing it along a particular api border seems unnatural.

this boundary is inherent in client-server software/systems/applications, there's just no avoiding it. every other API is basically unimportant and arbitrary.

the whole Web paradigm, the fact of "you need to download the site and run it" and the consequences and trade offs that it implies are basically unavoidable.

> Anyway, I’m looking for a tool that could make this part of development simpler by joining all these efforts in a “project and process manager” way instead of maintaining multiple toolkits/configs or generators. The latter I know how to do. Been there, done that, fed up.

completely understandable, and we're in total agreement. I also think that this is an underserved problem.

It's ridiculous that we still don't have near-perfect abstractions for these.

every other API is basically unimportant and arbitrary

Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Since for a user the page is always in sync with its server, this api is an implementation detail as much as any other internal api (e.g. between service processes or between async-threads)

Why do you think that the project separation is unavoidable in this case? E.g. some of my sites are simple express apps serving scripts and resources. I don’t have integrated build pipelines there because… well, that is exactly my concern. There seems to be no reason that we couldn’t have an ~isomorphic project with multiple entry points on multiple “ends” and a single build system for all of them.

I don't think it's unavoidable, but in practice it is two separate components with markedly different concerns and trade offs.

For example if we don't use any client side JS, use only a templating system, it becomes easy to keep it one project.

Eg. there's NextJS, which is a bundle of React and a NodeJS backed in one project. (And while it provides a getStaticProps and other gimmicks it doesn't really do much to make client-server state sync seamless. I still have to manually write the /api stuff.)

https://github.com/t3-oss/create-t3-app + Pnpm monorepo

Reply on news.ycombinator.com