Comments (16)
I would selfishly like you to go the Engine/Gem route since your newly-gained expertise would be useful for https://github.com/18f/answers. That said, it definitely adds some extra labor and complexity.
from c2.
I suspect that the constituency of clients that would consume this service that also have Rails currently in their stack is not super high. Delivering as a web service would make the service available to a much wider swath of consumers.
You're going to have the debt of backwards compatibility anyway - might as well incur that with the instrument that gives you a greater adoption likelihood.
from c2.
Why can't a Rails Engine/gem be a consumer of the API? Now you have two problems :)
from c2.
An API-driven approach is what we're all about, and I like that a lot. But it seems weird to break this up to follow a API/REST strategy if the clients will still all need to use Ruby and Rails engines.
Also, the top part says the API core would handle sending notification emails, but you have "Email sending/handling" listed as something the clients would each need to do themselves.
from c2.
Maybe I was unclear: the central component (be it a gem or an API) would handle the actual sending of emails in either case. Making C2 API-driven means the clients could implement template-building with whatever language they want.
from c2.
I'm -1 on Rails Engines. I think they do a lousy job of splitting out concerns. Think of all the Rails projects that end up tightly coupled to Devise.
Given these options, I would vote for an API and a Rails client implemented as a Gem. The Gem acts as dogfood and a reference implementation.
Careful, though. REST and State Machines are known to not play well together. For example, if you expose your carts as resources, you don't want clients to be able to update their state directly (really, you probably don't want to allow any updates to cart via the API), because you want to control that. Actions (on carts, etc) can be created, and then a mess of complicated backend logic is executed to resolve cart state. It all starts to look very unRESTful ...
Why do you need to do this re-architecture now? How many different use cases do you have so far? Is the complexity really slowing you down? How long will it take for this refactor to pay off in terms of time saved?
I'd consider a more incremental route. Figure out your data model ... create that separation of concerns within Rails. You'll have more flexibility to experiment and avoid locking yourself in to bad decisions. Once you feel you have it nailed down, it'll be trivial to release a public API.
from c2.
REST and State Machines are known to not play well together.
Yeah, the state changes would happen within C2. The primary use of the API would probably be to kick off approvals, and maybe check state.
Why do you need to do this re-architecture now? How many different use cases do you have so far?
Three, and hopefully growing.
Is the complexity really slowing you down?
No, but I worry that the longer we wait, the more difficult it will be to detangle.
How long will it take for this refactor to pay off in terms of time saved?
Hmm, hard to estimate. We already have an API for cart creation, so it's mostly a matter of deciding how the templates are specified/passed, and separating the client code. Nothing is blocking or slowing us down right now, but it's a matter of hedging future technical debt.
from c2.
I guess my main point is that i don't think simply separating the code into multiple repos gets you any of the architectural things you seem to be after. All of the hard can almost certainly be done in place.
Nothing is blocking or slowing us down right now, but it's a matter of hedging future technical debt.
Given that these aren't pressing concerns (and there aren't any performance/scalability issues), it looks like the incremental route is the right way.
from c2.
I guess my main point is that i don't think simply separating the code into multiple repos gets you any of the architectural things you seem to be after.
My main interest is enforcing separation of concerns, and increasing reusability. Nothing is stopping us from continuing to put everything in the one codebase, but it will get harder and harder to change that course. "Monolith" isn't quite the right term because it contains a bunch of loosely related things... maybe an "n
olith", or a "mosh pit"?
from c2.
I've always gone with "monorail" when we're talking about Rails apps.
Anyway, I think the monolith/monorail is underrated.
Splitting things out actually adds a ton of complexity ... the infrastructure orchestration problems suddenly become nontrivial, you can no longer just rely on the database to maintain consistency, and that's not even getting into the new abstractions that you have to build into the app to communicate with the other services.
Then there's the performance issues. That's usually the driver for splitting things out ... you remove a specific bottleneck from the app and implement it in a way that it has a different scaling factor. But, you still have to balance that with new problems like latency and failure modes. And of course, performance issues rarely crop up where you expect. To make a argument from performance, you have to measure everything and have the data to back it up.
So, I'm still a -1 to all of this. Building the API into your monorail (note: you can spin up extra instances that only handle API traffic without splitting out the rest of the code) for now seems like the best course of action. You can still practice good separation of concerns within the monorail and avoid a bunch of extra complexity.
from c2.
+1 on @cpapazian comment of keeping everything in one app as long as it can handle it.
@afeld is there something going on with the current architecture that prompted you to rethink the architecture?
It seems to me that we should collect user feedback before rebuilding things...
from c2.
I think Service Oriented Architectures made up of smaller, more modular parts are good things. I think the web is moving away from monoliths, and that that's a good thing. This doesn't feel like modularity in the SAO sense, though, since it sounds like API clients would be pretty tightly coupled to the internal functioning and technology stack of the API server. I could be misunderstanding.
from c2.
@konklone SOA is great. It is what everyone is moving to and it makes things easier to scale and allows for proper separation of concerns. I just think that in some cases the overhead of having a atomized system is not worth it.
Particularly, in this case, I would not prioritize re architecting the app just for the sake for being more modern...
[edit]: would _not_ prioritize
from c2.
@dlapiduz totally, 👍 to all that.
from c2.
I agree with keep everything in one place until you really understand the use cases and exactly what the app will need to do. It's hard to achieve separation of concerns, when you keep changing what you are concerned about. Monorails are really easy to refactor and change, then split up when you know your app and API are delivering the right value.
Maybe you are already on it, but I would be investing in metrics, KPIs, maybe a dashboard that is visible to stakeholders whose users are consuming API (through other products) as well as your UI. May seem off-topic, but I've seen success metrics change architecture and, of course, user experience.
from c2.
Closing as stale.
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.