I have an application that is using JDBC to manipulate its data.
I'm looking for a way to run the application on Appengine. Unfortunately, it seems like there aren't many options besides datastore (which I just can't get used to).
I've tried to use an embedded JavaDB, but Appengine blocks FileOutputStream (throws an exception "java.io.FileOutputStream is a restricted class" on initial driver loading). Therefore, I haven't tried Sqlite.
I've also tried to use Jiql, a new project that offers a JDBC interface to Datastore. However, I just can't seem to establish a "connection". It is somewhat unclear to me how to use jiql (like: what user/pass do you supply?), despite the few examples on their site.
I've looked at Google Cloud SQL and eventually signed up for it. It seemed to be the perfect solution to our problem, until I realized it's a paid service (it'll be paid soon, once it leaves the beta phase). I prefer not to pay (yet) as I'm still testing and evaluating the potential of GAE.
--
What would you recommend, keeping in mind would like to use JDBC for the persistence layer of the application?
Thanks in advance!
GAE supports two frameworks for persistence, JPA and JDO. There are few frameworks that plays well with GAE rules like Objectify. But to start with datastore you can also take at google tutorial GAE DATASTORE. If you need to learn the relationship with JPA and support for JDBC persistence Check this Link
Related
Currently I am making an app where I want to have all the dependancies as orderly as possible. With my app running Elixir on Google's Compute engine, I think, for my (SQL) database, to use the PaaS solution that Google Cloud itself provides.
This being the case, I went looking for an adaptor and unfortunately found none. However, under the impression that SQL is itself a standard, I wonder how hard it might be to use an existing adapter like Ecto.Adapters.Postgres or Ecto.Adapters.SQL with the login information of my platform.
Is this something that is possible, and furthermore what type of protocol is implied by using the predominant adapters? Is it simply a RESTful api or is it something a little more proprietary to postgres?
If you're using Google Cloud SQL (it's unclear from your question) then judging by this documentation and especially this passage:
"administer your relational MySQL databases on Google Cloud Platform"
then you should be able to use the MySQL adapter for Ecto. Unless I'm misunderstanding your question and if I am, then please add some detail to your question so we can give you a better answer.
If you've already researched this option then please provide more detail about what's not working for you.
Can an application developed on Google App Engine be run any where else without heavy modification? I mean at a cooperate/private server?
If you are developing using GAE and GWT alone and not using any of the GAE specific services like mail, blobstore, memcache then you have nothing to worry about. You get tied down to GAE to the extent you use GAE services only. That said, you have to watch how you are accessing DataStore, as low level API's are going to lock you down to DataStore.
I haven't tried using AppScale and am assuming you were asking if you could host your web application on a standalone Tomcat/Glassfish server with a conventional RDBMS.
AppScale and TypoonAE are both projects which attempt to allow you to host your own App Engine compatible projects. Both are quite young and chasing the moving target that is GAE.
This question has been addressed elsewhere
You can use Appscale.
Please, refer to this post.
I recently had to realize a project on Google AppEngine. At the beginning I was sceptic. But there a some really nice approaches on Appengine:
No server setup. Everything works out of the box. Gzip, libraries, etc.
One-Click-Deployment. Fire up GAE Launcher on the Mac and click DEPLOY. Done.
Low costs
Easy in-production-logging
But there are some things I don't like if I'm thinking about professional projects
The blobstore. It's just... weird. And non-backupable
All the 1 MB restrictions
The feeling that your code will only run on AppEngine. (BigTable)
Do you know any similar alternatives to AppEngine? And I don't mean services like EC2.
You can have a look at AppScale
Its an open-source implementation of AppEngine which you can deploy on your own machines, with a host of databases to choose from.
I think Heroku is a great alternative.
It can run most of GAE existing apps, since it supports django, but also:
It supports Ruby (w or w/o Rails), Java (w or w/o Spring), Node.js, Clojure,...
It has a strong CLI support (git push for publishing, creation of apps, scaling, log, ps,...)
It supports MySql and PostgreSQL (and, so on, MongoDB, Amazon RDS, etc.)
It has a free tier for 750 hours a month (~1 machine always up) for every app.
It has a collection of addons for providing cloud services as a resources for the apps
It has an add-on program to develop your own add-ons.
Really, it is a good alternative.
If you want your application is not binded to GAE, the best approach is to use well-known langs and well-known persistence providers. Ruby+PostgreSQL, for instance, could be a combination very portable. Django as well, but w/o BigTable...
AppScale and TyphoonAE are both third-party implementations of the App Engine platform. TyphoonAE is targeted at small-to-medium scale, while AppScale is targeted at the large-scale end of things.
As far as backing up the blobstore goes, this is quite doable: just use the built in handler to serve blobs, and, in conjunction with remote_api, you can download your blobs just fine.
I almost hate to mention Microsoft in a Google-related question, but I'm completely vendor-agnostic. So, I'll offer Microsoft's Azure as a platform that offers many similarities to AppEngine but enough differences that it might fit as a good answer to your question.
Azure and AppEngine are similar in that they are both designed to allow you to build easily scalable applications. Azure gives you Microsoft's standard web toolkit options: C#, VB.NET, ASP.NET ASP.NET MVC, but also offers PHP. It has a NoSQL, document database like AppEngine but also gives you the option of choosing a more standard instance of SQL Server. Although I haven't used it myself, it looks like AppEngine for Business now offers SQL, too.
Azure gives you a ready means of having long-running background processes. AppEngine does not to the best of my knowledge.
From my perspective, AppEngine has the huge advantage of charging you for usage only when a request is actually being processed. An Azure instance causes you to get billed even for time that it is completely idle. That's entirely typical, but the fact that Google doesn't so it that way makes me choose AppEngine every time. My budget is too tight to allow me to spend money for idle CPU hours.
There's a port of django to non-relational databases that works with app engine or mongodb.
google for django non-rel
documentation is a bit sparse though
I currently have a Grails application I'm evaluating to port to Google App Engine and I'd like to know experiences regarding:
Acegi security: the application relies on this library to enforce the security (update: just learned that it's based on hibernate so can't be ported; any recommended replacements?).
Use of JPA or JDO instead of the hibernate plugin (I'll have to migrate the Domain classes); which one is better ?
I have a growing number of pre-generated pdf files I keep uploading; is there any foreseeable problem with this?
Thanks in advance.
This isn't the answer you want, I'm sure, but I spent some time exploring Grails on GAE and finally came to the conclusion that it's not a good fit. By the time you give up (or work around) the native Domain capabilities, forego many of the plugins, and deal with the host of other minor incompatibilities, you've essentially wiped out most of the productivity advantage of Grails. I'd consider a standard J2EE, a compatible framework, or possibly a GWT based app for GAE. If you want to stick with Grails, I'd host it on AWS or a dedicated J2EE hosting provider.
That said, I hope the integration eventually works cleanly because GAE is a pretty cool engine/model.
You may also be interested in Gaelyk (http://gaelyk.appspot.com/) Gaelyk is a lightweight wrapper which enables you to deploy applications written in Groovy to the App Engine.
Gaelyk offers a lot of the advantages of Grails including:
standards for Views, Controllers
flexible URL routing
plugin system
It has simple wrappers for the App Engine (including datastore access and coercion to POJO/POGOs, email, memcache, Jabber & more)
(although it doesn't include internationalisation, CRUD scaffolding or a HQL type query wrapper)
As it is more lightweight it doesn't have the performance issues on App Engine that Grails does and now that you can reserve instances
http://code.google.com/appengine/docs/adminconsole/instances.html#Always_On it is possible to remove the startup time problems!
I wrote a blog series about my experience with Grails on App Engine. It discusses most of your questions.
What is the current status of grails and google app engine deployment. I am new to app engine but wonder worth exploring it. Some specific qns are
the latest plugin, which has high user rating, has any restrictions? or it work seamlessly with all gorm features
is there any issue with high startup time for grails application. How is it in real world scenario? (with a typical small and large scale application)
what about other grails plugins (like, shiro, joda time, nimble etc). I guess they wont play well. So using those libraries directly is the better option
If decided to give up goole-app as a deployment option, how easy to switch to a normal environment. The JPA support ensures the compatibility with other traditional DBs?
Not sure what else are major issues.. probably, this is the foundation for a good discussion.
thanks.
I got few good response from grails mailing list, and the conclusion shares the comment by David. see the thread here
Couple of relevant responses:
From Tomas Lin:
I would suggest looking into Gaelyk if you really want to build a
project on the App Engine. It is built from the ground up with the App
Engine as the target engine, so it can bypass problems like long
loadtimes due to Spring and Hibernate. The newly introduced plugin
mechanism guarantees that your Gaelyk applications can be extended in
a way guaranteed to work on GAE.
Gaelyk has it's own native entity persistence DSL, which is a little
cleaner that the JPA/JDO abstractions on top of the App Engine.
I currently see many HardDeadlineExceeded exceptions with the App
Engine and Grails. It is just not designed to work well with Spring
right now. Hopefully this will improve with the later releases of
Groovy, Grails and the Spring / Google partnership for GAE for
business, but I wouldn't consider Grails on GAE production ready.
Even with Gaelyk, there are reports of slow performance. So imagine
the difficulties that arise with the much bigger Grails stack.
The app-engine comes with it's own implementation of a user / security
management system based on GMail accounts. If you just want to provide
an admin / non-admin implementation, this is supported in the
appengine configuration. Cannot comment on Shiro.
Be aware that one of the major restrictions of the App Engine is the
inability to write a file, so even basic file uploading in Spring
becomes problematic since the default mechanism writes to a temporary
file. I would imagine that most of the plugins would not work out of
the box without digging into their code and changing it.
I think the biggest issue here is lack of support for native JDBC. JPA
is not as well supported as plain JDBC GORM, things like named queries
would probably not work out of the box without retrofitting. If you
want to use the latest and greatest parts of Grails, it might be
worthwhile to consider other hosting solutions.
From Aaron Eischeid
1.The GAE plugin and the JPA-GORM plugins combined do not get you all GORM features seamlessly. Though you should get basics like .save(), .delete(), and maybe .list() the dynamic finders etc. are going to be out (at least for now). I could be way off here, but I think most/all Hibernate dependent features are out or replaced by something else (since it relies on SQL under the hood and GAE doesn't currently have SQL based DB...) so for example any criteria builders are a no go. It is unclear to me how much of the dot drilling you can do on objects. For example, not sure if you could do something like:
def b = new Book()
def stores = b.authors.publishers.bookstores
One place I could use some pointers is how to use JPA in the domain classes. I am sure there is good info out there, but I just haven't found it yet.
unsure
grails plugins that include domain classes or manipulate your current domain classes are bound to have issues since you have to construct your domain classes differently to play nice with JPA which is necessary because Googles Datastore isn't quite like a relational DB. On the flip side. you can use Google's built in security so you shouldn't necessarily need plugins like Acegi or Shiro.
This probably boils down to the different levels of GORM that you can use in controllers and services and the different ways you define domain classes. Some refactoring seems inevitable unless JPA plays just as nice with SQL DB's as it does with Googles Datastore. If JPA can move like that then transferring should be easy, but by using JPA-GORM you give up some stuff you would probably want if you weren't benefiting from due to being on GAE.
Eager to hear what others have to say,
Aaron