question about large scale setup

13 views
Skip to first unread message

Steve Frank

unread,
Jan 18, 2017, 10:06:32 PM1/18/17
to praxis-support
I'm researching praxis as a possible starting point for some microservice work and was wondering if there are any examples of how to organize the code for a large deploy and many microservices. 

1. we want as much isolation between teams as possible.
2. that being said, we want core fabric, utilities, middleware to setup the golden path for how to construct a microservice

how have you done it at rightscale? i assume you have more than one service deployed using praxis. if so, do you use a git repo per service? do you have common libraries?

we are coming from rails where we are heavy into rails engines. we have some core engines that give the rest basic functionality, like logging, metrics, tracing, admin consoles, health check endpoints.

i was experimenting with that in praxis and it kinda worked, but i had to really hack the whole "Application.file_layout.groups" code to insert classes from an external repo.

Additionally, examples of "praxis to praxis" communication would be helpful. I am not completely certain what the right way to code controllers is to validate user input. And then along those lines, do you use any tools to generate client code for us in other services? i saw some gem that will generate angular code, but didn't see anything for ruby (other than maybe PoC code).

The way that praxis forces you to design the api first is such a huge selling point. Even the folder is called "design." I love it. I'm excited to keep learning about it.

Thanks!


Josep Blanquer

unread,
Jan 26, 2017, 1:05:03 PM1/26/17
to Steve Frank, praxis-support
Hi Steve,
 
 
See my responses inline.

On Wed, Jan 18, 2017 at 7:06 PM, Steve Frank <st...@cloudhealthtech.com> wrote:
I'm researching praxis as a possible starting point for some microservice work and was wondering if there are any examples of how to organize the code for a large deploy and many microservices. 

1. we want as much isolation between teams as possible.
2. that being said, we want core fabric, utilities, middleware to setup the golden path for how to construct a microservice

how have you done it at rightscale? i assume you have more than one service deployed using praxis. if so, do you use a git repo per service? do you have common libraries?


I cannot really speak for RightScale, they can chime in to comment on it if they want. But in general I don't think Praxis dictates any of that behavior, it's really open to however you're used to organize your ruby code. In general I think that the best pattern is to indeed have 1 repo per service (but I think that's not a Praxis-specific pattern, it's just a best practice to you can individually develop and deploy services in a decoupled way).
Common libraries are certainly a very normal pattern as well, with the caveat is that APIs are versioned so you have to make sure the shared assets are appropriately versioned (or organized by version) as well, to avoid backward changes etc.

 
we are coming from rails where we are heavy into rails engines. we have some core engines that give the rest basic functionality, like logging, metrics, tracing, admin consoles, health check endpoints.


Yes, one can follow much of that in Praxis apps as well, but you have to put it together (there aren't specific helpers or code for it, as it is very personal and there isn't a universal way to do it). In particular (just to pick some of the ones you list above):
* Health-checks: are easily shareable across apps. They're commonly unversioned so the code can basically the same (i.e., from a common gem).
* admin consoles: all Praxis apps have the console (through `praxis console` or `rake praxis:console`)
* Tracing/metrics: it depends, but if you use NewRelic, for example, you can use the gem for it, which is extremely simple to setup (basically it requires just including the gem). There is also some support for Statsd.
* Logging and other things are commonly simple so I see that you can probably move that onto a common gem or shared code...but it depends on your setup as well.
 

i was experimenting with that in praxis and it kinda worked, but i had to really hack the whole "Application.file_layout.groups" code to insert classes from an external repo.


I am not sure what you're trying to do with that, I have never had to hack any of that myself for any project. I can probably help if you explain what you need. (have you used the bootstrap hooks, for example? that allows you to inject code before or after any of the bootstrap stages...)

I would also recommend looking at the Praxis Plugins for any of the shared code or extensions. They are a really powerful and clean way to extend your apps.
 
Additionally, examples of "praxis to praxis" communication would be helpful. I am not completely certain what the right way to code controllers is to validate user input. And then along those lines, do you use any tools to generate client code for us in other services? i saw some gem that will generate angular code, but didn't see anything for ruby (other than maybe PoC code).


1- Yes, currently there isn't a public set of examples to Praxis-Praxis communication. But at the end of the day, that's equivalent to REST talking in ruby, so nothing really special.
2- Controllers to validate user input? Nothing should be done there, as long as the validation has been defined in the design...the framework will do that for you (and coerce the objects appropriately). Controllers should only validate complex business logic that is too custom to express in the design DSL.
3- I personally haven't use client tools. Rest-client (in Ruby) and similar are very easy to use when the API is mostly a CRUD restful one. There is some work that was put together about a year ago to generate swagger docs (so you could use swagger client gen tools)...but the wasn't completed (there was no ask for it to begin with)
 
The way that praxis forces you to design the api first is such a huge selling point. Even the folder is called "design." I love it. I'm excited to keep learning about it.


Thanks for the interest, and I hope these answers help you.

Cheers,

 Josep M.
PS: I do not know if you're aware of it, but since you're a Rails shop, you should know that there is some support for using Praxis "embedded" into your Rails app...so you can build it with the same design-first philosophy etc, but being able to reuse any code that you want in your controllers (i.e., ActiveRecord models...etc). I'm just saying this because building new controllers in this way, for an already working Rails app is a breeze (and provides a very fast way to get new APIs up and running for large Rails codebases, without having to bite the bullet of creating new apps from scratch to mimic that behavior). 

Thanks!


--
You received this message because you are subscribed to the Google Groups "praxis-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-support+unsubscribe@googlegroups.com.
To post to this group, send email to praxis-support@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-support/b8f39a52-eaa4-4844-b20b-b55dc15ce978%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages