Multiple gateways

[Gaël Marziou]

I am applying BFF pattern which leads me to at least 2 gateways:

- one for angular app for human access

- one for mobile access

The 2 gateways expose different subsets of the backend apis and have different authentication requirements.

This is working very well, great job team!

I also created an anonymous gateway for local testing and I was delighted to see I could use --skip-client, --skip-user-management and databaseType="no".

:)

Gael

[Deepu K Sasidharan]

Could you share a diagram or something of your setup?  Just for educational purpose :)

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/e57bb13b-e9b5-49cf-bfb3-b7471d1b61c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gaël Marziou]

I will draw something tonight, I guess it could be shared as a tip for people like Matt doing Ionic dev.

[Gaël Marziou]

Here it is.

- the anonymous gateway can be used in dev by tools to put some load on services, it has no authentication and in fact it can simulate a hard coded user or device. A variant of it could be to delegate authentication to a front reverse proxy using 2-way SSL
- the webapp gateway is the "classic" jhipster gateway hosting a jhipster angular app
- the mobile gateway is dedicated to mobile devices access, authentication can depend on type of apps (public or pro) and be based on user or device

Each gateway may expose a different subset of services.

Some gateways are more critical than others and may require more instances to scale up.

Another approach that is possible is to use a common gateway for webapp and mobile if authentication is the same and assign them different roles.

As usual it depends ;)

[Deepu K Sasidharan]

Nice +1

--

You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/03f94b09-78a8-4667-9f69-ac53b638ee26%40googlegroups.com.

[Julien Dubois]

Yes this is really nice!

We should have a "microservice architecture" page, with some sample diagrams to show how you could use JHipster.

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CAFXry56mHdZT-jUb-03Rih8AJMwr6qxRW04-u8TdH1tmTC8SMg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Julien Dubois

Twitter: @juliendubois
Phone: +33 (0)6 25 02 34 18

[Deepu K Sasidharan]

Yes that would be good for people to understand how to use Jhipster 3.0

[Gaël Marziou]

I could start a page on v3_preparation and we could improve it together.

Docker's role also deserves a good description in this architecture and I'm not the right person for it.

[Julien Dubois]

Yes indeed!

We should describe different architecture, and how we can still easily develop (and deploy!) our app using Docker.

Can you start with the diagrams?

On Thu, Mar 10, 2016 at 2:47 PM, Gaël Marziou <gael.m...@gmail.com> wrote:

I could start a page on v3_preparation and we could improve it together.

Docker's role also deserves a good description in this architecture and I'm not the right person for it.

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/75ab4e0c-377a-4478-bfe4-ac673af764fb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Matt Raible]

I agree that architecture descriptions would be nice. I also think this is a great quote from Jay Kreps:

"Microservices are about scaling the number of engineers not the number of requests”

https://twitter.com/jaykreps/status/704551744227799040

We might want to encourage teams of < X to use JHipster as a monolith. I don’t know if X is 10 or 50, but I’d hate to encourage people to spin up 5 servers for a simple app / small team.

Thoughts?

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CADNXADEP%2BLdNoNLj%2BXK0Se%3DGeuP4khhs%2BA_VjpwrTFb_0PAtyw%40mail.gmail.com.

[Julien Dubois]

I agree that most people won't need microservices, and we must be clear about that.

It's just an option of the generator, and by default people should use the "monolith".

Then, of course, it's a very interesting and exciting option. I also expect that much bigger projects/companies will use JHipster because of this option.

Julien

[Gaël Marziou]

We might want to encourage teams of < X to use JHipster as a monolith. I don’t know if X is 10 or 50, but I’d hate to encourage people to spin up 5 servers for a simple app / small team.

More than team size, I think that team maturity is a more important criteria.

MSA has many benefits and some drawbacks too, tools from Netflix tend to lower the disadvantages.

The good thing about JH3 is that it helps you to quickly setup a micro services architecture and you can quickly evaluate whether it does fit your project or not.

I don't think we should recommend one style versus the other because our criterias may not be the same as our users.

I just hope that we won't see many questions on SO by people who did not take the time to read Spring Cloud/Netflix docs, as we often see from users who did not take time to learn about frontend development or Spring Boot before starting to use JHipster.

Gael

[Christophe Bornet]

+1 to clearly state that micro-services is not for your 5 people lean start-up