So we’re building an Angular 2 application (I may have mentioned this before). It’s been a fun and frustrating experience- but in reality, most of that is our own fault. Using a still developing framework comes with risks- the main one being that both the framework itself and the best practices for that framework can change at any time. Just when I figured out how to really use the EventEmitter, I read that we should just use Subjects instead. And they’re great- both an Observable and a Subscriber in one! But it can be frustrating to learn that all you learned is obsolete as soon as you learned it.
Anyway- I’m actually really liking Angular 2 (I just also like to complain). The tougher part has been the .NET backend. I had no prior experience with .NET, so it’s been another steep learning curve. And that separation of my knowledge base (good with JS, bad with C#) led to an idea for separating our project code bases. Is it a good idea? I have no idea.
The premise is to have the Angular front end running on a simple Node server. That keeps our frontend project in the JS space and Angular and Node just seem to play well together. All that Node server needs to do is serve up the front end, so it was fairly easy to build (and I really like Node, so that part was fun). Then, the .NET backend runs on IIS (which also play well together). Each backend module will be its own .NET project (one for login/users, one for product A, one for product B, etc). Then, we just treat those as internal APIs- the frontend asks for the data (JSON) and displays it, the backend’s job is just to provide it. They communicate via JSON web tokens for authorization. We don’t have to try to get Angular working on IIS and have it all bunched up in one monolithic project.
It seems like a good idea. Modularization is all the rage right now, and it’s also something that was emphasized with this project’s design (some clients may subscribe to some features, while others subscribe to different features- they need to be self contained). This way, it also paves the way for exposing public facing APIs in the future- the structure is already there because we are already using it internally, we just have to provide the key.
Again- I don’t know if this is a good idea or bad idea or if it’s the way something like this is actually supposed to be done. I never claimed to be a software architect- I was a JS developer that got pushed into the backend. But it does seem to work, and does seem to check off all the boxes for the project specs, so we’re going to give it a shot!