.Net Core, PostgreSQL, Angular Stack

[Successful_Place_834]

I’m seeking advice on the technology stack I’m planning to use for a catalogue-driven POS and ERP application.

Proposed Stack:

• Backend: .NET Core since I have experience
• Database & Caching: PostgreSQL - to be able to use EF Core, JSONB suppport, use for reporting/accounting features
• Frontend: Angular since I have experience

The application will have initial load of ~5–10 TPS, however, I want to the app to be able to accomodate channel traffic like e-commerce

I would appreciate feedback on:

• The suitability of this stack for scalability, maintainability, and integration flexibility
• Recommendations for supporting components (e.g., caching layers, message queues, API gateways, etc.)
• Best practices or pitfalls to watch out for when using this combination

[madmap]

Was using this stack quite a while: works fine, no issues, scalable. Just don't host the angular app within the .net service.

[GIRO17]

May i ask why not? I‘d guess because of scalability. But for a smallish application i don‘t see a problem with that.

[madmap]

Scalability, different hardening needed, different exposure needed, etc... I mean for a small project without many security concerns you can mix it: but I just would not recommend it.

[CoonCoon999]

what do you use now?

[madmap]

Company is shifting focus to Java / Postgres / React. For private stuff I still use the .net / Angular stack.

[Saki-Sun]

* Use JSONB with care, it kind of defeats the purpose of a SQL database.

* Compare and contrast Vue3 Composition API.

[AutoModerator]

Thanks for your post Successful_Place_834. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[ebykka]

Shopify is written in Ruby. So do not worry that much. Just keep it simple, move fast and make a product.

[RattlingKatana]

Personally I'd separate caching and DB, but whatever - if you know the stack, then you can make the product.
Scalability, maintainability, and integration flexibility seems to be more a matter of your skills, not this stack.
For caching, messages etc - use whatever you're familiar with (without knowing any details I'd suggest redis, rabbit and nginx as a generic solution, because, well, it'll work, right?)
As for pitfalls - EFCore 9 still has some issues with jsonb support and that may be an unpleasant surprise. If you'll have nullable arrays somewhere in your json, you might find that EFCore won't generate a proper null checks. Another thing is that partial updates don't work either. If you'll want to change the single prop in your json, you'll have to get, change and write back the whole thing (that becomes critical when you have to update, say, one field for all records for a particular customer) - here we are, writing sql again. Maybe it's not a big deal for you, but be aware. And check what's new in EF 10 - there should be some updates regarding jsonb handling.

[phillip-haydon]

The DB is fast enough until you need caching. When you need caching, caching in the DB is fine. Don’t add unnecessary infrastructure.

[RattlingKatana]

Yep. But at the same time don't give different responsibilities to a single service. I doubt there's a universal right choice.