{"_id":"5613396904683b0d0087bd73","title":"Introduction","user":"5600910981a9670d006d144f","__v":41,"githubsync":"","link_external":false,"order":0,"project":"56000f0d8c0c9d0d00dcad21","version":"56000f0e8c0c9d0d00dcad24","api":{"results":{"codes":[]},"settings":"","url":"","auth":"required","params":[]},"body":"[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/s8t4Lu03ThijipSkbioQ_space-header.jpg\",\n        \"space-header.jpg\",\n        \"1570\",\n        \"590\",\n        \"#526da1\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nSpace helps you build *scalable* business applications in Meteor with *fast* and *reactive* task-based UIs backed by *well-tested business logic*. Scaling your app to a big audience becomes trivial using *modules*, *microservices* and *distributed messaging* – core features of the framework.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Ship Features Regularly\"\n}\n[/block]\n**Successful business applications tend to grow fast.** You want to be able to ship new features regularly without getting bogged down by poorly structured code or regression bugs. This is exactly what Space was made for. It is a set of well known patterns for structuring and testing large-scale applications with Meteor. \n\n## Modular Application Architecture\nSpace promotes loosely coupled components following the *Single Responsibility Principle* and gives you full control over configuration and initialization of your application. Your decision to use certain 3rd party packages (e.g: for *routing* or *rendering*) should not become major stumbling blocks down the road. Space enforces clean *Separation of Concerns* to make it simple to switch gears while driving your business on the speedway!\n\nLearn how to structure your code with Space.\n\n## Expressive Testing\nThe only way to fast iterations in software development is a good testing suite. You need the confidence that all existing features continue to work as expected when you are releasing new versions of your app. The Meteor testing frameworks are great but you need a lot of boilerplate even for basic regression tests. Space provides expressive BDD testing APIs to make testing the complex parts of your app fun again.\n\nLearn how to test your application with Space.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Impress your Customers\"\n}\n[/block]\n**Your customers want ultra-responsive interfaces and hate waiting.** Confronting them with loading spinners (because your reactive joins are slow) is not a viable solution. They don’t care about your database and scaling issues, either you got it right or they will move on. Space features two patterns that will make your app incredibly fast:\n\n## Denormalized Data\nIs the key to fast and scalable applications. This is especially true with Meteor, because MongoDB and live queries were not made for relational data models and joins. To make your app blazingly fast, you need to tailor your data model to the UI, so that queries always stay simple and effective. Space allows for denormalizing of data, so you can impress your customers with super snappy interfaces.\n\nLearn how to denormalize your data with Space.\n\n## Reactive UI with Flux\nThe default templating system in Meteor is nice but often results in badly structured frontend code in large applications. When using the standard templates and managers, many people start spreading view logic into places where it becomes hard to manage and test. Space provides a package that brings Facebook’s Flux pattern to Meteor. This way you can centralize application state into stores and build simple, re-usable components that reactively display the current state and publish events when something happend. Flux is the perfect match for Meteor's reactivity and it already saved us countless hours of fixing hard-to-debug errors in the UI.\n\nLearn how to build your frontend with Space\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Build a Solid Business\"\n}\n[/block]\n**You cannot predict what questions about your customers you will ask in 1-2 years.** *Planning is guessing*: things always tend to turn out different than imagined or planned. Still, most companies act as if they already know what information about their customers and usage patterns will be important next year.\n\nTo build a solid business, you must *ensure* that you will be able to ask any kind of question about interactions with your app. And of course not just about the recent interactions, but about all interactions that ever happened to the system! Only then you will be able to analyze and evaluate your business strategies.\n\nTo make this possible, Space brings the battle-tested concept of Event Sourcing to Meteor: *Storing all the changes (events) to the system, rather than just its current state.*\n\n**This brings (amongst others) the following advantages:**\n\n  * **History**: Having a true history of the system. Further benefits such as audit and traceability.\n  * **Answers**: You can ask any question about your system/users at any time.\n  * **Time travel**: Ability to put the system in any prior state. (I.e. what did the system look like last week?)\n  * **Flexibility**: By storing all events you can create arbitrary *denormalized data projections* at any time in the project. This enables you to present your data in any number of ways and *optimize it for the UI*.\n  * **Speed**: Events are always appended, never updated or deleted which makes storing them blazing fast.\n\nLearn more about Event Sourcing with Space.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Scale to a Big Audience\"\n}\n[/block]\nMeteor is a great platform for building real-time apps, but scaling it to thousands of concurrent users often becomes the first major pain point in production. Reactive-joins, complex live queries and too-fine-grained subscriptions can quickly bring your app to a grinding halt. Denormalizing your data and tailoring subscriptions to important use-cases can already bring big speed improvements but Space promotes two patterns that will make your app scale without limits: \n\n## Microservices\nAt some point you will have to split up your application into distributed modules that can be scaled individually. For example, your internal admin interface (4-6 users) will have very different scaling needs than your customer-facing application (thousands). Building big monoliths has never been a sustainable strategy and with Meteor it became even worse, because it sends all templates / frontend code to the client, no matter if you ever show them to the user. When developing your application with Domain Driven Design principles and Event Sourcing in mind, you automatically split it up into well-encapsulated modules that can be moved into separate Meteor apps at any time in the project! The domain events of your aggregates already are the API contract between your modules, which brings us to the next pattern…\n\nLearn how to split up your application into microservices.\n\n## Distributed Messaging\nNormally this is really hard and requires you to manage clusters of app processes with IP addresses etc. Most people cringe when they have to think about complex setups with multiple microservices talking to each other (and justifiably!). The key difference that Space brings to the table is (you guessed it): Event Sourcing. Since all communication on your (monolithic) server already happens via events and commands, there is literally no difference when switching to microservices. You just need to configure a shared MongoDB collection for your apps and Space does all the hard work for you! Each app will receive events and commands only once (no matter how many processes) and there is not a single other code change necessary.\n\nLearn how to setup distributed messaging with Space.","hidden":false,"link_url":"","sync_unique":"","category":"56000f0e8c0c9d0d00dcad25","excerpt":"","type":"basic","updates":[],"createdAt":"2015-10-06T03:00:57.924Z","slug":"introduction","childrenPages":[]}
[block:image] { "images": [ { "image": [ "https://files.readme.io/s8t4Lu03ThijipSkbioQ_space-header.jpg", "space-header.jpg", "1570", "590", "#526da1", "" ] } ] } [/block] Space helps you build *scalable* business applications in Meteor with *fast* and *reactive* task-based UIs backed by *well-tested business logic*. Scaling your app to a big audience becomes trivial using *modules*, *microservices* and *distributed messaging* – core features of the framework. [block:api-header] { "type": "basic", "title": "Ship Features Regularly" } [/block] **Successful business applications tend to grow fast.** You want to be able to ship new features regularly without getting bogged down by poorly structured code or regression bugs. This is exactly what Space was made for. It is a set of well known patterns for structuring and testing large-scale applications with Meteor. ## Modular Application Architecture Space promotes loosely coupled components following the *Single Responsibility Principle* and gives you full control over configuration and initialization of your application. Your decision to use certain 3rd party packages (e.g: for *routing* or *rendering*) should not become major stumbling blocks down the road. Space enforces clean *Separation of Concerns* to make it simple to switch gears while driving your business on the speedway! Learn how to structure your code with Space. ## Expressive Testing The only way to fast iterations in software development is a good testing suite. You need the confidence that all existing features continue to work as expected when you are releasing new versions of your app. The Meteor testing frameworks are great but you need a lot of boilerplate even for basic regression tests. Space provides expressive BDD testing APIs to make testing the complex parts of your app fun again. Learn how to test your application with Space. [block:api-header] { "type": "basic", "title": "Impress your Customers" } [/block] **Your customers want ultra-responsive interfaces and hate waiting.** Confronting them with loading spinners (because your reactive joins are slow) is not a viable solution. They don’t care about your database and scaling issues, either you got it right or they will move on. Space features two patterns that will make your app incredibly fast: ## Denormalized Data Is the key to fast and scalable applications. This is especially true with Meteor, because MongoDB and live queries were not made for relational data models and joins. To make your app blazingly fast, you need to tailor your data model to the UI, so that queries always stay simple and effective. Space allows for denormalizing of data, so you can impress your customers with super snappy interfaces. Learn how to denormalize your data with Space. ## Reactive UI with Flux The default templating system in Meteor is nice but often results in badly structured frontend code in large applications. When using the standard templates and managers, many people start spreading view logic into places where it becomes hard to manage and test. Space provides a package that brings Facebook’s Flux pattern to Meteor. This way you can centralize application state into stores and build simple, re-usable components that reactively display the current state and publish events when something happend. Flux is the perfect match for Meteor's reactivity and it already saved us countless hours of fixing hard-to-debug errors in the UI. Learn how to build your frontend with Space [block:api-header] { "type": "basic", "title": "Build a Solid Business" } [/block] **You cannot predict what questions about your customers you will ask in 1-2 years.** *Planning is guessing*: things always tend to turn out different than imagined or planned. Still, most companies act as if they already know what information about their customers and usage patterns will be important next year. To build a solid business, you must *ensure* that you will be able to ask any kind of question about interactions with your app. And of course not just about the recent interactions, but about all interactions that ever happened to the system! Only then you will be able to analyze and evaluate your business strategies. To make this possible, Space brings the battle-tested concept of Event Sourcing to Meteor: *Storing all the changes (events) to the system, rather than just its current state.* **This brings (amongst others) the following advantages:** * **History**: Having a true history of the system. Further benefits such as audit and traceability. * **Answers**: You can ask any question about your system/users at any time. * **Time travel**: Ability to put the system in any prior state. (I.e. what did the system look like last week?) * **Flexibility**: By storing all events you can create arbitrary *denormalized data projections* at any time in the project. This enables you to present your data in any number of ways and *optimize it for the UI*. * **Speed**: Events are always appended, never updated or deleted which makes storing them blazing fast. Learn more about Event Sourcing with Space. [block:api-header] { "type": "basic", "title": "Scale to a Big Audience" } [/block] Meteor is a great platform for building real-time apps, but scaling it to thousands of concurrent users often becomes the first major pain point in production. Reactive-joins, complex live queries and too-fine-grained subscriptions can quickly bring your app to a grinding halt. Denormalizing your data and tailoring subscriptions to important use-cases can already bring big speed improvements but Space promotes two patterns that will make your app scale without limits: ## Microservices At some point you will have to split up your application into distributed modules that can be scaled individually. For example, your internal admin interface (4-6 users) will have very different scaling needs than your customer-facing application (thousands). Building big monoliths has never been a sustainable strategy and with Meteor it became even worse, because it sends all templates / frontend code to the client, no matter if you ever show them to the user. When developing your application with Domain Driven Design principles and Event Sourcing in mind, you automatically split it up into well-encapsulated modules that can be moved into separate Meteor apps at any time in the project! The domain events of your aggregates already are the API contract between your modules, which brings us to the next pattern… Learn how to split up your application into microservices. ## Distributed Messaging Normally this is really hard and requires you to manage clusters of app processes with IP addresses etc. Most people cringe when they have to think about complex setups with multiple microservices talking to each other (and justifiably!). The key difference that Space brings to the table is (you guessed it): Event Sourcing. Since all communication on your (monolithic) server already happens via events and commands, there is literally no difference when switching to microservices. You just need to configure a shared MongoDB collection for your apps and Space does all the hard work for you! Each app will receive events and commands only once (no matter how many processes) and there is not a single other code change necessary. Learn how to setup distributed messaging with Space.