4 ms·
That is interesting! Do you find that setup useful for CRUD-style apps too? What parts of your application would typically be written in WASM then? I am asking
by graboid 3y ago
That is interesting! Do you find that setup useful for CRUD-style apps too? What parts of your application would typically be written in WASM then? I am asking because if I look at my usecases, I mostly see rendering logic done by a JS framework and a restful API that does little more than serving the frontend by querying the DB and mapping between models.
- torginus 3y agoWell, I had 2 apps written this style in recent memory. One was adapting an existing app with a React frontend and a .NET backend to work in an air-gapped place - we just replaced all the backend calls to calls into the WASM runtime, which did its thing internally. The other was rearchitecting a microservice-based app, where the .NET server basically only served as middle-man, calling into other various services. Eliminating this middle-man and integrating it into the client allowed us to serve the whole thing statically from CloudFront which massively simplified our infra situation. I think where .NET shines is writing big, complex applications, for a simple CRUD app where the only thing I do is prod a database, I'd just go with a simple nodejs server. In my experience, I tend to write all business logic in the back-end, and the front-end's job is mainly just presenting it to the user, so even with fancy SPAs, the bulk of the complexity lives in the back-end. Keep in mind, that with all the super-duper trimming and size optimization options MS has added to .NET, the runtime is still multiple megabytes, so adding WASM .NET to your typical consumer website isn't super feasible, it's more for these niche use cases.
- graboid 3y agoThanks for the details, appreciated.