Admin UI for creating users
phirefly opened this issue · comments
One note about the architecture here that could save you years of headaches if you think about it early on.
Any time a client is providing data to configure your application, it comes at a significant cost to both you and the client. For this email case, it's just about creating users, but then in a few months it might be define request flows, or more complex org unit structures, or whatever. Client data is never static but changes every few weeks or months, so the setup required for your application is an ongoing cost of doing business with you forever, and one which both sides resent.
Here's the scenario that leads to disaster. First, you build a great approval app that requires emails, roles, org units, office addresses, project codes, etc.. It's kind of a pain to set up, but there's an admin UI so at least you don't have to deploy new code for each client, and you have to get the data in there somehow after all. Then next year, they have a new request for an app, SurveyManager.gov, that serves a different purpose but guess what, it uses a lot of the same data, because that data is particular to the client, not to the application.
Now, an honest developer on SurveyManager.gov who wants to deliver quickly will start a new isolated application, and build out all the framework for uploading and validating the data again, except this time the data model is slightly different because they choose a slightly different database schema to better fit their application. Furthermore, the developer begins to rely heavily on those peculiarities of the data model.
Now the client has to upload their same data to two different apps in slightly different formats to the same organization (you). Ok, you probably see where I'm going with this: zoom ahead 5, 10 years - now you have 20 big clients and 10 applications, and all of the sudden each client is uploading and configuring almost the exact same data to you 10 different times, and you are fielding support cases from 200 uploads of data every month. This cripples your development efforts, your organization looks incompetent, fire rains from the sky and into your coffee, etc..
Once you are in this situation, it is nearly impossible to get out, because it would essentially be rewriting all of your applications since each one was written depending on the peculiarities of its data model. Even that nuclear option - rewriting all of your applications - is barely feasible, because in the B2B case (or G2G in your case), all of your clients have developed processes around your applications and the peculiarities of their data models, and you cannot change anything without significant cost to their workflows.
There is a simple solution to this if you plan for it now, and that is to have a Common Data Repository that houses all configuration data provided by the client. At first, this can be very simple - just have a separate git submodule that lives in your ruby codebase that handles client provided configuration data. It should take a connection string as a parameter, but you can point it to your same application database. That way, you start to enforce separation of concerns early on without incurring additional infrastructure complexity. When you start building another application that uses some of the same data, you can reuse that submodule if the new application is in ruby, but start a new database which is the Common Data Repository, and now point both submodules to the same db. At this point, you have introduced some infrastructure complexity, but at a great benefit to the client, and introduced very little additional code complexity, perhaps offset by reuse of code for validations, data loading, etc.. At some point, you want to access the CDR from a python app, then it will start to make sense to turn it into a web service, but you can still write a python client to make accessing easier, but that's a long way down the road.
Now it's 5-10 years later in this rosier scenario. Your 20 clients and 10 applications just need 20 configurations (ie, 1 per client). Furthermore, this architecture significantly encourages them to build another app with you since it will not be an additional ongoing setup cost for them - they will see only the benefits. You also get the usual benefits of modularity - ie, an improvement in the CDR performance or usability automatically improves all apps.
So, that's my lengthy pitch for thinking very carefully about client provided configuration data, since it can end up being by far the largest cost of the application suite to both developers and clients if it is not handled properly from day 1. My short term pitch is that anything that accepts client provided configuration data should be in its own submodule as a way of enforcing separation of concerns early on.
The linked tracker story is no longer available (guessing it was deleted). We have active admin implemented now and that could be used to create a user via admin panel, technically. I am not sure how @anthonygarvan 's comments are related, since I can't see the original story. But I am going to close this since it is not actionable given the deleted ticket.