00:00:22.000
Hello everyone, my name is John Crepezzi. You can find me on Twitter as CJohnRon. Just a brief introduction about myself: I really like Ruby, which is why I'm here today. I also enjoy beer, and I gave a demonstration of this last night. For anyone who missed it, don’t worry—there will be a repeat performance.
00:00:30.720
I've worked on a few projects, such as Ice Cube, which is a game recurrence library, and Easy Translate. These are just a couple of things I've contributed to. I currently work at Patch in New York, and I’d like to encourage anyone who lives in New York or wants to move there and is a Ruby developer to come find me. We do really interesting things and support open source contributions.
00:00:50.480
Today, we will discuss splitting your app. First, we'll talk about what it means to split an application. Next, we will discuss why you would want to do that. After that, we'll talk about how to make it happen and when the best time is to implement such a shift into your planning.
00:01:01.920
When I refer to splitting your app, I’m talking about two main things. The first is services: we aim to break our applications into smaller pieces to take advantage of the benefits associated with services. The second aspect is APIs. As we break the app into smaller components, there's no reason those components can't serve as APIs on their own. These APIs might be public-facing or serve internal functions for different parts of your business.
00:01:36.640
So, why should you care? The correlation between scaling and splitting your app is significant. Imagine trying to lift something that is tightly coupled and grows large—it becomes cumbersome. Each of us probably manages multiple database machines or applications, and splitting our app at the model level can aid in scaling effectively. We must also consider splitting our application at the application level itself, identifying ways to scale components like the model side or controller side independently.
00:02:00.079
This is often something we don’t think about until it becomes a pressing issue. Recently, at Patch, we saw our user accounts grow from 30 to 850 in just three months. This explosive growth highlighted the necessity of scaling our applications and thinking ahead about how to expose APIs or services. Initially, one might simply add APIs directly into their existing controller actions, coupling the responses tightly.
00:02:39.440
As you start adding response formats like JSON or XML directly into your controllers, it can quickly become unmanageable as you're coupling multiple concerns together. You might find yourself editing response mechanisms in many places without a clear maintainable strategy. This leads to situations where your controller logic and response formats become conflated.
00:03:02.480
The next step might be to create a dedicated folder within your controllers specifically for API interactions. This approach allows you to isolate API-specific logic while continuing to return structured responses appropriate for API consumers. However, this can also lead to duplication as both your regular and API controllers may need similar logic, forcing you to maintain code in two different locations.
00:03:36.639
Eventually, one solution is to extract the API logic into a completely new application. By building a separate application that handles the API, it becomes easier to manage and iterate on without the constraints from the original structure. Doing so allows you to offload certain tasks, creating a streamlined API without sacrificing performance.
00:04:02.240
To avoid duplicating logic when creating this new application, focus on shared models and services. The goal should be to write less code that achieves more, maintaining readability while reinforcing strong separation of concerns. We don't want all developers building the same thing; rather, we should strive to share our code effectively and think about how different teams can leverage existing architecture.
00:04:41.120
I’ve worked on some tools that can assist with this process. The first is called Flexible API, which allows you to include methods that can dynamically create hashes of attributes, making it easier to handle multiple formats and variations in requests without extensive duplications of logic. Additionally, there's the Flexible API Server, a Sinatra application that serves as a small proxy sitting on top of your models to facilitate different types of requests.
00:05:33.760
Our approach to structuring requests is dynamic, enabling users to specify which fields they care about at different request levels. This flexibility allows us to handle data differently based on the context of the request. We can specify what data is necessary without overwhelming our clients with unnecessary information. As we enhance these capabilities, we ensure our API remains lightweight while encapsulating relevant logic.
00:06:11.840
Furthermore, we can introduce inheritance into our API structure to further refine access controls and functionality based on user roles or request levels. Extending the server allows us to manage additional logic when necessary, ensuring that all components align with our overall application strategy.
00:06:57.360
We’ve also been able to decouple certain features of our application while still maintaining robust testing frameworks. By employing a testing strategy that integrates unit tests, we can ensure different components of the application work as expected even when changes are made. This is especially crucial in maintaining the stability of the application as it evolves.
00:07:38.160
A key aspect of our implementation is the ability to handle errors gracefully. When a validation fails, the system returns a structured error message, allowing clients to understand exactly what went wrong. This clarity is essential for maintaining robust client-server interactions and helps ensure users can troubleshoot their requests or data submissions effectively.
00:08:18.760
As we tackle issues related to routing and versioning, we've focused on ensuring that various components can communicate without duplication. The implementation of well-defined API endpoints allows for easy adjustments when needed, enhancing the flexibility of our services. The expectation is not only to create scalable solutions but to develop processes that accommodate growth and iteration in our applications.
00:09:10.159
In conclusion, while splitting your application can certainly introduce complexity, it also creates opportunities for growth and specialization. I encourage all of you to think about how this model might apply in your own projects and how we can share ideas and solutions to facilitate better software architecture.
00:09:49.839
I’m open to questions or feedback. Thank you!
00:10:03.000
If there are specific concerns, such as handling specific types of records within the application, we can extend functionalities within our models to accommodate those requests. This can be done by adding specific controller logic that allows for fine-tuning of the data seen by different user types.
00:10:30.000
This approach has been successful because it keeps our application robust yet flexible. By managing request levels and using tools like flexible API and flexible API server, we avoid redundancies and ensure that our application grows in a manageable way based on user needs.
00:10:49.000
Is there anything else you'd like to discuss or any additional questions? Your input is valuable as we strive for continuous improvement.
00:11:20.000
We have implemented strategies to address various scaling challenges while ensuring smooth operations as we evolve. Thank you all for your attention today!
