Talks
Splitting Your App
Summarized using AI

Splitting Your App

by John Crepezzi

In this talk titled "Splitting Your App", John Crepezzi discusses an effective technique for dividing web applications into manageable components, focusing on creating a streamlined API using Sinatra. The discussion is structured around key concepts and practical strategies that developers can implement to enhance application scalability and facilitate easier API integration.

Key Points:
- Introduction to Application Splitting: John introduces the concept of splitting web applications into services and APIs to leverage benefits such as improved performance and easier management.
- Importance of Splitting: He emphasizes the correlation between scaling and application splitting, stating that tightly coupled systems become unmanageable as they grow. This point is illustrated with his experience at Patch, where user accounts expanded dramatically, necessitating a rethink of their application structure.
- Separation of Concerns: The talk highlights the need to separate API logic from traditional application logic to avoid code duplication and maintain cleaner architecture. John advocates for creating a dedicated API application to manage responsibilities effectively without impacting the performance of the main application.
- Tools and Strategies: John shares tools like Flexible API and Flexible API Server that aid in dynamically handling requests with less code duplication. These tools facilitate better management of different response formats based on client needs.
- Testing and Error Management: He emphasizes robust testing strategies, including unit tests, to ensure the application’s stability during ongoing changes. Moreover, he discusses the significance of clear error handling to improve client-server interactions.
- Routing and Versioning: John talks about the implementation of well-defined API endpoints, allowing for easy adjustments and communication between components, ultimately facilitating growth and iteration of the application.
- Conclusion: The session concludes with John's encouragement for the audience to consider how splitting their applications might apply in their projects while sharing ideas to improve software architecture. The complexity brought by splitting can lead to improved specialization and growth potential in applications.

Overall, John Crepezzi's presentation provides a comprehensive guide for Ruby developers seeking to enhance their application's architecture through effective splitting techniques, ensuring scalability while maintaining clean, manageable code.

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!
Explore all talks recorded at Ruby on Ales 2011
+8