I am learning Angular. I am struggling to understand how to use Angular2 and MongoDB together. Some tutorials refer to using Express.js. I'll prefer to stick to 4 technologies- Angular, Play, Scala and Mongdob ( I want to avoid learning another new framework).
Without Angular, I know how to store/retrieve data in Play using Reactive Mongo (data being sent to server as JSON, backend application in Scala). However, if I make the frontend in Angular, I guess I should make a service to handle database interaction. My doubts are:
1) When should I connect to the database? It doesn't seem wise to connect to database for each service API call
2) If my connection to database drops, how would my application know?
3) the communication with the database should not be blocking. How do I handle this? I guess there would be some 'Promise' somewhere but I do exactly know how to use it
If any backend programming is required, I'll like to use Scala instead of Java
Related
I'm searching a simple implementation to push changes from a free relational database (PostgreSQL, MySQL, SQLite, etc.) to clients' browsers via WebSocket or WebPush.
I want to avoid all the server-side JavaScript ecosystem (Node.js, npm & cie) and the NoSQL databases.
All must be hosted in the servers of my company, I can't use third-party services.
I found these interesting solutions :
http://initd.org/psycopg/articles/2010/12/01/postgresql-notifications-psycopg2-eventlet/ [with Python]
https://gist.github.com/drocco007/6e44ac1a581546c16e67 [the same one slightly improved]
https://coussej.github.io/2015/09/15/Listening-to-generic-JSON-notifications-from-PostgreSQL-in-Go/ [with Go]
Do you know other ways to get this done?
Is PostgreSQL the more suitable free RDBMS to do this?
Can it be accomplished with a SQLite database?
Can Apache or NGinx abilities be used to achieve this?
Update 01/23/17: I wrote an application called postgresql2websocket in order to send PostgreSQL notifications over websockets using Python 3 with asyncio + aiohttp + asyncpg https://github.com/frafra/postgresql2websocket; you could combine it with PostgREST in order to have both standard REST APIs and realtime updates using WebSockets.
As far I know, there is no HTTP server extension for using SQL databases with Websockets without anything in the middle.
You can use Python on the server side, like this: Real Time Web Apps with (just) Python and Postgres. I think it could be improved thanks to aiopg. If you don't need Websockets, you can just use ngx_postgres.
If you like Django, Django Channels will be probably included in Django 1.10 (Redis/in-memory/... layer for channels and SQL backend).
You could use SQLite, but bear in mind that you have to implement a separate server side publish/subscribe mechanism (like Django channel does), because SQLite doesn't have one.
If you're just interested in pub/sub over Websockets, you could use Webdis (Redis-based solution): it would be probably lighter than a full SQL database.
I am somewhat new to the domain of web development. I am investigating Play2 and am trying to understand, do you need some kind of JS frontend framework to go with Play2 and Scala?
I notice that Play2 has a template engine, but it seems that it generates the HTML on the server and sends it to the browser. Does this mean that the need for a JS frontend like Angular2 is made irrelevant? Or is there still a reason to use Angular2 in a Play2 application? What instances would it make sense and why?
I have some experience of using Play 2 with AngularJS (currently rewriting frontend to Angular2).
I use Play 2 (scala) only for RESTful JSON backend, which is just great for this purpose and I use Angular for single page application frontend. I find this combination brilliant.
My project is hosted on GitHub, you can check it out here
There are three directories in the root:
restful with all backend stuff, written in scala, using Slick for DB,
taking advantage of Play evolutions and all other stuff.
angularjs-client-deprecated with AngularJS code. I used angular-resource for making calls to backend.
client with Angular2 code. There is nothing there so far except for my experiments, however I've written a simple service for authentication with security token.
To summarise, I've been developing my project for almost 2 months so far, mainly to learn both Scala and AngularJS (now Angular2).
If you're planning to use JS framework for frontend, I would recommend you to use Play2 only for RESTFul Json backend. I don't see a reason to use Play2 html template engine in this case.
Play is more about Server Side templating, which isn't all that useful if you're using Angular. It can be done, but it comes with some overhead. I've worked with Scalatra in the past and it worked really well for me.
http://scalatra.org/
Other options include Spray, which is very similar from the outside, but uses Akka internally and uses non-blocking I/O, similar to Play!
http://spray.io/
With angular it is better to go with simple rest/http api like Akka-IO or spray for data and other stuff. Play will be less relevant with Angular.
As others have pointed out Play2 isn't really the best option for building responsive websites. I have a seed project which can help you get started with Akka Http and Angular 5...already configured to deploy to Heroku in a single web dyno.
https://github.com/jdschmitt/akka-angular-heroku
Check it out. I hope it helps anyone landing here looking for a way to manage back-end and front-end in a single repo for simple projects.
We have a web2py application that we want to connect to an EmberJS client. The idea is to use the responsive capabilities of EmberJS to keep the client updated writing minimal code.
We have (REST) primitives which are in charge of creating / updating the underlying datastore (CouchDB). These primitives are sometimes complex and covering corner cases, involving the creation of several documents, connecting them, validating configuration parameters, ... This is implemented in the backend. We would like to avoid duplicating the full modelling of the data in our EmberJS application, and avoid duplicating the logic implemented by those primitives.
I have some questions:
does it make sense in EmberJS to just model a subset of the data in the documents? We would just create models for the small amount of properties that the user is able to interact with. The client would not see the full CouchDB documents, just the data necessary for display / interaction.
is it possible to connect EmberJS to a REST interface, without having to fully model the underlying data in the database?
does it make sense in EmberJS to just model a subset of the data in the documents?
Yes. There is no need to create ember models for objects/properties that user will not need to interact with.
is it possible to connect EmberJS to a REST interface, without having to fully model the underlying data in the database?
Definitely that is possible, it's a fairly common use case. The best way to get started is by building a small MVP that works with just couple of models. Once you've got that wired up it will be easy to add more domain objects.
The tricky part (especially at first) will be mapping your rest endpoints to the ember-data REST adapter. The adapter will work out-of-box with some REST endpoints - see the REST Adapter - but connecting a CouchDB datastore will probably require some customization. The tools for this are still evolving, have a look at ember-data integration tests to see what is available.
I'd like to start practicing JS server-based stuff in a real-world environment (not localhost) and AWS seems to be the most economical way to do this. And I'd like to start by using Backbone in conjunction with REST.
If I do this, is REST out-of-the-box ready on AWS and it's just a matter of throwing my Backbone code on the server? Or is it a matter of configuring the REST API on AWS?
Thanks in advance!!!!
As the comments indicated, web applications are broken up in to two parts, the client and the server, and Backbone is an exclusively a client-side library ...
... well, almost. There is a server-side Javascript web framework called Node.js, and if you really wanted you could use Backbone on it. Alternatively you could run a more traditional server-side language/framework like Ruby/Rails, Python/Django, etc. If you are using AWS's EC2 service you basically get your own computer to do what you want with, and you can use Node, Django, or whatever else to write a REST-ful webservice that your client-side code can use.
I'm developing a website with a Lucene backend. Lucene connects directly to index files, making it difficult to develop the website from machines other than the index machine. Traditional databases have a server running to provide an intermediary between the raw data and the application.
I would like to create such an intermediary between Lucene and my web application. On first thought, Akka seems like the right tool, and I think I would use Akka futures or typed actors to perform the call. However, the Akka Typed Actors page warns:
"A bit more background: TypedActors can very easily be abused as RPC, and that is an abstraction which is well-known to be leaky. Hence TypedActors are not what we think of first when we talk about making highly scalable concurrent software easier to write correctly. They have their niche, use them sparingly."
I think the point is that RPC promotes centralization, but is my plan a good one or an abuse of Akka?
Why not use solr? It provides the application to manage your lucene indexes (as it is basically lucene with an application over the top to interact with the data. It would be easier than dealing with actors and it should provide everything you need.