Development Fun
The past week has been fun. While I don't dive into specifics about work projects I can talk frameworks and general hurdles as well as frustrations.
Generally speaking, I've been prototyping the next gen of software for our internal applications developers. This involves a transition to a microservices architecture running on .Net Core and in Docker containers.
We have a lot of technical debt, and I probably can't jettison it all. And much of it I don't need to abandon. After some evaluation I've decided NHibernate fits with our legacy needs better than moving to EF. And OData remains top priority despite some potential hurdles as I evaluate moving to .Net Core 3.1.
The technological upgrades are exciting. We were using Spring.Net for dependency injection before. But, there appears to be native support. And while it isn't on the same level as Spring.Net I would readily argue that we never took significant advantage of it at the level where it mattered.
As I thought about it, it mattered most that I could define interfaces or abstract classes and allow the developers to choose the implementation to inject. And Asp .Net Dependency Injection has some life cycle notions that either didn't exist or which we weren't taking advantage of in our old architecture which simplifies the heck of a lot of things. Namely, Singletons, Scoped and Transient. I haven't yet had a need for Transient, but the mix of Scoped and Singleton dependencies being injected reliably... it is a beautiful thing.
We have a multi-tenant architecture. And each tenant has their own DB connection. In a scaleable multi-threaded app, being able to generate a scoped session and transaction, while maintaining a session factory as a singleton without the need to worry about this on my own is AMAZING. I feel like our old architecture is from the stone age.
Now, the NHibernate choice probably sounds a bit odd. EF has grown a lot. But, 2 of our historical features have included User Defined Fields and scripted, incremental DB updates. EF is much more strongly typed and makes extending the model dynamically with user defined fields a lot harder. We also have a lot of existing work I can lean upon for things like adding support for our UDFs inside of queries.
And while scripted updates aren't exactly off the table with EF, NHibernate's lack of maturity makes it less tempting to try and mix concepts like having EF manage the schema.
OData is where things get a little fuzzier. I owe no particular allegiance to OData. But, oddly, I don't feel like the alternatives are better. MVC seems like to fully expand my entities whether I want it to or not. GraphQL is fine if you don't need an open API of consistent support. gRPC doesn't appear to be as widely supported as OData either. But, oData appears to have some issues with versioned endpoints in .Net Core. Thankfully... I don't really need versioned endpoints.
Basically, what I like about OData is that I can define a ful hierarchy across a huge number of tables, and let the developer worry about how much or little they want to pull across. It is less clean than GraphQL when it comes to UI, but UI isn't our only use case. We have integrations and we can't anticipate what they will need ahead of time necessarily. Combined with the universal and largely consistent support and you have a winner in my books.
It is a bit frustrating that it appears to be losing prominence. If there was a clear winner to take its place, I would feel differently. But for our needs, there is no alternative.
Anyway, this low level architectural stuff is insanely fun to build out. I just hope we ultimately end up making use of it.
Generally speaking, I've been prototyping the next gen of software for our internal applications developers. This involves a transition to a microservices architecture running on .Net Core and in Docker containers.
We have a lot of technical debt, and I probably can't jettison it all. And much of it I don't need to abandon. After some evaluation I've decided NHibernate fits with our legacy needs better than moving to EF. And OData remains top priority despite some potential hurdles as I evaluate moving to .Net Core 3.1.
The technological upgrades are exciting. We were using Spring.Net for dependency injection before. But, there appears to be native support. And while it isn't on the same level as Spring.Net I would readily argue that we never took significant advantage of it at the level where it mattered.
As I thought about it, it mattered most that I could define interfaces or abstract classes and allow the developers to choose the implementation to inject. And Asp .Net Dependency Injection has some life cycle notions that either didn't exist or which we weren't taking advantage of in our old architecture which simplifies the heck of a lot of things. Namely, Singletons, Scoped and Transient. I haven't yet had a need for Transient, but the mix of Scoped and Singleton dependencies being injected reliably... it is a beautiful thing.
We have a multi-tenant architecture. And each tenant has their own DB connection. In a scaleable multi-threaded app, being able to generate a scoped session and transaction, while maintaining a session factory as a singleton without the need to worry about this on my own is AMAZING. I feel like our old architecture is from the stone age.
Now, the NHibernate choice probably sounds a bit odd. EF has grown a lot. But, 2 of our historical features have included User Defined Fields and scripted, incremental DB updates. EF is much more strongly typed and makes extending the model dynamically with user defined fields a lot harder. We also have a lot of existing work I can lean upon for things like adding support for our UDFs inside of queries.
And while scripted updates aren't exactly off the table with EF, NHibernate's lack of maturity makes it less tempting to try and mix concepts like having EF manage the schema.
OData is where things get a little fuzzier. I owe no particular allegiance to OData. But, oddly, I don't feel like the alternatives are better. MVC seems like to fully expand my entities whether I want it to or not. GraphQL is fine if you don't need an open API of consistent support. gRPC doesn't appear to be as widely supported as OData either. But, oData appears to have some issues with versioned endpoints in .Net Core. Thankfully... I don't really need versioned endpoints.
Basically, what I like about OData is that I can define a ful hierarchy across a huge number of tables, and let the developer worry about how much or little they want to pull across. It is less clean than GraphQL when it comes to UI, but UI isn't our only use case. We have integrations and we can't anticipate what they will need ahead of time necessarily. Combined with the universal and largely consistent support and you have a winner in my books.
It is a bit frustrating that it appears to be losing prominence. If there was a clear winner to take its place, I would feel differently. But for our needs, there is no alternative.
Anyway, this low level architectural stuff is insanely fun to build out. I just hope we ultimately end up making use of it.
Comments
Post a Comment