I started looking into Grails and I felt quite comfortable writing a simple prototype web app with services, controllers, a RESTful interface and some simple views.
The usual way for deployment would be to package the web app into a .war (or .zip for plugins) and then deploy it to a application server e.g. Tomcat.
Assuming I will integrate the frontend into a larger existing frontend/portal, I don't want to package this together with some potentially heavy backend and put all this on the same application server, which was originally meant to host frontent/portal code only. Also the backend might provide services to be used by other applications.
Thinking about flexibilty in scalability, is there a possibility (or the need at all?) to seperateley deploy the frontend (views, maybe some controllers) and the backend (maybe the REST controllers?, services, domains) to different hosts, by packaging two separate modules? Anyone having experience rolling out a Grails app in large scale?
Related
I have a project FE, BE and a DB.
now all the tutorials I found use the three in one file.
Now should it be the DB in one docker-compose file and the BE and FE in another?
Or should it be one file per project with DB, FE and BE?
[UPDATE]
The stack I'm using is Spring Boot, Postgres and Angular.
Logically your application has two parts. The front-end runs in the browser, and it makes HTTP requests to the back-end. The database is an implementation detail of the back-end and not something you separately need to manage.
So I'd consider two possible Compose layouts:
This is "one application", and there is one docker-compose.yml that manages all of it.
The front- and back-end are managed separately, since they are two separate components with a network API. You have a frontend/docker-compose.yml that manages the front-end, and a backend/docker-compose.yml that manages the back-end and its associated database.
Typical container style is not to have a single shared database. Since it's easy to launch an isolated database in a container, you'd generally have a separate database per application (or per microservice if you're using that style). Of the options you suggest, a separate Compose file only launching a standalone database is the one I'd least consider.
You haven't described your particular tech stack here, but another consideration is that you may not need a container for the front-end. If it's a plain React application, the "classic" development flow of compiling it to static files and publishing them via any convenient HTTP service still works with a Docker-based backend. You get some advantages from this path like Webpack's hashed build files, so you can avoid disrupting running clients when you push out a new build. If you separate the front- and back-ends initially, then you can change the way the front-end is deployed without affecting the back-end at all.
I need suggestion on how best we can implement APIs for large scale enterprise application has a couple of child web applications running inside root application. For example Root, Child1 and Child2
There are separate MVP projects for each application is hosted in IIS. MVC apps have only front-end logic, business & data access layer is hosted in another WCF projects(a separate WCF project for every child). Front-end MVC app only routes requests to target WCF application.
Now I'm planning to design APIs for each application. I'm not able to decide whether I should create a separate application which will hold APIs for all the child and root application or should add API in each application. Like front-end MVC projects, APIs will also redirect to centralized WCF application.
There is a common logic applicable to all the APIs(rate limiting, authentication etc...), if API is in each application then I would have to replication logic in all the three apps.
There are trade-offs either way.
The advantages of developing separate APIs include;
Isolation
Easier to change
Independently deployable I.e. Can scale independently
Might be easier if different development teams are involved in the different APIs
The disadvantages include:
Need to decide if you want to repeat common code in each API or extract a common shared module (this then reduces the isolation advantage)
More infrastructure / ops to deal with
If you want coordination in terms of rate limiting across all APIs this is harder than if they are a single API
My default position would be to develop separate APIs, but your particular use case (routing requests to other things) might be solved by some existing tool such a nginx - I'm not knowledgable about these so cannot advise
I am currently developing an MVC app using asp.net. My final aim is to deploy the saas on Azure.
But would it be feasible to do it at a later stage or should i incorporate it into my development?
When it comes to use Azure authentication etc i will require that due to the app being multi tenancy.
Just wanted to know peoples thoughts on this?
Cheers
It would be better if you can provide more information. Do you want to know if you ignore Azure at the moment, how much effort you need to take if you decide to deploy the application to Azure? In general it would not take too much effort, unless you want to use Azure services, such as storage, ACS, and so on. Deploying an ASP.NET application to Azure web site is just like deploy to a remote IIS. Deploy to web role requires you to create an additional cloud service project. Deploy to virtual machine usually does not require any modifications to the project, but requires you to setup all the environment.
In addition, please note there’re still some difference between Azure and local environment. For example, we usually use Azure SQL Service instead of connecting to the local SQL server.
Best Regards,
Ming Xu.
I'm doing something similar, but without developing on Azure right now. I have prepared for it though by making sure I use interfaces as much as possible. For instance, I don't write to a file system using File and Directory, but to interfaces IFile and IDirectory.
If you can avoid assuming anything based on your current localised, Windows Server environment then you can at least write implementations to satisfy requirements that do work in Azure. I'm planning to deploy to Azure and local Web servers and use Dependency Injection to satisfy the concrete implementation of the interfaces. I could just as easily use the same codebase entirely and have it detect the environment before injecting the implementations.
I have a database on a database server. No web service in place to be consumed by a web application.
If I want my iOS app to communicate with a database server (send & receive data), I know I can create a web service and then call that service from my iOS app. But what web service is recommended for this? Should I just write a .asmx web service in .NET or should I go for MVC WEB API or may be go for WCF ?? I have spend hours doing research on this. Please help.
A lot will depend on where you expect the service to be hosted, and what technology stack(s) are supported by the host. If you are self-hosting, then do whatever works in the technologies you know and understand. If you want to use a host that targets its services to small-to-midsize independent development teams, many providers like Heroku support things like Rails services. PHP is always an option as well. Microsoft-based solutions and Java-based solutions tend to be more widely used in larger enterprises and data centers, and if that's where you'll host your service then these would also be good options. And of course I'm speaking in broad generalities here: For any general trends I might list here there are lots of exceptions where other approaches make sense.
If you'd rather let the decision be driven by what makes things easiest for your iOS code, I would recommend you start with server-side technologies that support REST-ful interfaces using JSON to represent your service's resources. REST-ful services are very easy to consume from iOS, and JSON-based representations of resources are very easy to parse and produce in Objective-C.
I am personally used this approach to set a direction for my app. For the service side, I am going with a Rails implementation of REST-ful web services. I'm a Java developer by profession, but for a small independent project the options for hosting Java services were more limiting than with Rails so I've picked up rails on the side to make my project work. So far it's suited my project quite well.
I would like to share the data access portion of my grails app (Grails domain classes and services) with another grails app. One is a standard client facing web app, the other (not yet written) will be for periodic background tasks such as reminder emails and such using the Quartz plugin or similar, where the UI will just be for statistics/control for internal users.
I do not want this all bundled in one Grails application because I want to be able to scale them and run them on different machines. What is the proper way to do this? I have accomplished this in the past in more legacy Java web applications by bundling the shared data access classes into a .jar and including them where needed in multiple apps, but I'm not sure if this is the right approach for Grails.
I've considered a full blown service oriented architecture where a third grails application is responsible for all data access and the two described do all their data access through REST calls to this service app, but this is out of scope for the short term since the client facing webapp is already written.
Usually this is done via plugins. Create your domain classes, services, controllers and even default gsp's that you want to share among apps and create them as a plugin. That way you can install them in any Grails app that requires that behavior.
I've done this with some generic accounting type behavior that is fairly common among apps I write like receivables, payables, etc.
One great thing is that you can write the plugin and test separately with a test data source and then when you install it into a Grails app it will use the apps data source. And it will have default gsp's and controllers that give you a basic set of behavior that you can override in the actual app.