Comments (2)
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.
from c2.
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.
from c2.
Related Issues (20)
- Onboarding for Robb HOT 6
- konacha / sprockets update HOT 1
- Onboarding Micah
- CVE-2016-6316 in rails HOT 1
- API isn't working HOT 3
- Date submitted bug HOT 1
- Blanket branding question
- Incorrect recurring interval value
- Incorrect Purchase Type Displayed
- Visual bug: new purch req form selector missing chevron
- Canceling a request doesn't cancel a request HOT 1
- Cookies are sent via HTTP instead of HTTPS HOT 3
- Add additional logging for ATO HOT 1
- Create user account for penetration testing
- Supervisor select box is extremely difficult to use
- Migrate email service off Mandrill
- The mail job is failing HOT 3
- Remove "micropurchase" from gsa18f options
- Remove references to cg-fake-uaa
- ?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from c2.