Server Side Rendering

[zachariahtimothy]

I was playing around with this library and really like what it has to offer, but I was curious if you do or are going to support Server-Side Rendering/Universal Javascripts/Isomorphic/

Love the design by configuration, hope to use this soon!

[DominikGuzei]

Hey @zachariahtimothy! Great to hear that you like what you see :wink: The space framework itself is not directly tied to any rendering framework (Blaze / React / Angular) and you can easily create an application with either of these technologies.

Currently space:ui only has direct support for blaze-components (via a simple mixin) but if you want we can work on a simple solution for React + Server Side Rendering!

PS: We are currently releasing brand new major versions of the packages and the docs are not yet updated to all the API changes and improvements! When things are settled (within the next few days), we will write about the news in the forums and crater.io :wink:

PPS: The best way to learn everything about the space framework and various packages will be the docs: https://meteor-space.readme.io/docs/ (will add a lot of content within the next days!)

[zachariahtimothy]

Awesome, that all sounds great. I look forward to seeing the documentation progress. Is the new major version going to be substantially different? Should I be waiting for it to start implementing or may I begin now? Also might be useful to add a doc section showing how to use space in a package. Currently, I am building my app out of packages instead of directly into the project. Thanks!

---

Zach Curtis P: 970.590.6383 E: zachariahtimothy@gmail.com T: @zachariahCurtis https://twitter.com/#!/@zachariahCurtis

On Mon, Oct 19, 2015 at 5:23 PM, Dominik Guzei notifications@github.com wrote:

Hey @zachariahtimothy https://github.com/zachariahtimothy! Great to hear that you like what you see [image: :wink:] The space framework itself is not directly tied to any rendering framework (Blaze / React / Angular) and you can easily create an application with either of these technologies.

Currently space:ui https://github.com/meteor-space/ui/ only has direct support for blaze-components https://github.com/peerlibrary/meteor-blaze-components (via a simple mixin) but if you want we can work on a simple solution for React + Server Side Rendering!

PS: We are currently releasing brand new major versions of the packages and the docs are not yet updated to all the API changes and improvements! When things are settled (within the next few days), we will write about the news in the forums and crater.io [image: :wink:]

PPS: The best way to learn everything about the space framework and various packages will be the docs: https://meteor-space.readme.io/docs/ (will add a lot of content within the next days!)

— Reply to this email directly or view it on GitHub https://github.com/meteor-space/base/issues/10#issuecomment-149374809.

[rhyslbw]

@zachariahtimothy

Docs are being evolved continuously, so you can review what we already have, and ask questions in the Gitter room if there's anything in particular you need to understand.

We're almost done releasing the new versions now, so you will be right to just jump in when you can add space:flux into your app from Atmosphere :-) This is the direct replacement for space:ui, will start out at 0.6.0, but we plan to move it to 1.0 when we are happy with the test coverage. Check the example application to get started.

We also employ a package-only application architecture in our own projects, and will be doing the same with a more complex example app in the near future. If you understand Domain Driven Design, package up a Space.Module for each Bounded Context, and your Space.Application separately. With the Application you add the Bounded Contexts using the RequiredModules array. This allows you to break your system into multiple Meteor apps with minimal code refactoring if you need to scale independent parts.

[zachariahtimothy]

@rhyslbw Looking at the source code of space:flux, stores and helpers are exported to client only. I looked through some React Flux examples supporting Isomorphic apps and noticed they use the same stores server and client side which makes sense to ensure predictable behavior within the application. Will space:flux 1.0 support stores on the server side or am I way off the mark?

[rhyslbw]

@zachariahtimothy Let me preface this by saying that one of the primary values Space provides is a framework for building opinionated pattern-libraries. The majority of the code comes from the framework's lower-level packages (base and messaging), so if the opinions expressed in the two we currently offer space:flux or space:event-sourcing don't align with your requirements, or you're looking to implement a new pattern, it's just a matter of building a new module :-)

We use CQRS principles along with a server-only Domain layer, so the Space.flux.Store only has the responsibility maintaining Component state by subscribing to UI events and wiring up to data sources for reactive updates such as a View Cache (read model). We use Aggregates in the domain to manage business logic, which is very similar to the idea of a server-based store, but with better separation of application and business concerns. Taking this approach allows for multiple applications to be built as consumers, with distributed architectures allowing for natural scale.

Maybe a solid example of a server-based store would help to drive out some understanding.

[zachariahtimothy]

@rhyslbw thank you so much for the quality and intelligent responses! I love the Meteor community for this conversation right here. The truth is I am new to Domain Driven Design but I keep getting "got" by not having a solid architecture in place for my Meteor apps. Trying to learn as quick as I can, I ask for examples because I am a monkey see, monkey do kind of guy :) Thanks again!

[rhyslbw]

Yes we hear you :-) Maybe take a look at the pre-production releases of the Space Accounts packages to review modules working together in different layers:

In DDD terms, space:accounts is a Generic Bounded Context that would suit many systems. (Notice the distinct lack of direct references to Meteor code ;-) ). The tests are good to review as they express the functionality.

space:accounts-ui is the application service layer, that is also generic for many systems since the view is omitted. A closed-source project we're working on is using Semantic UI with Blaze Components, so we have built space:accounts-ui-blaze-semantic to suit, but also to serve as a reference module. The views could easily just be written straight into your application code with just the two parent packages pulled in via Atmosphere.

Overall, learning DDD, CQRS, and Event Sourcing is worth the learning curve as when you come to tackling a more complex challenge, you'll know about patterns that can help. The best bit is they are timeless concepts and technology agnostic :-)