Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I want to know your suggestions about a good back-end to use with AngularJS as a front-end.
Why is your suggested back-end good and is it easy to use, or easy to learn?
There is considerable risk in this question for opinion-based answers, so I suggest a more critical evaluation:
Restful server-side implemenations
... Will make working with angular considerably easier and less painful as well as being true to the HTTP spec with all the good things that entails. In any language that you choose ensure that the framework allows for the minimum of effort in doing this.
In my experience:
PHP:
Vanilla PHP and Codeigniter are capable but poor at doing this, I suggest avoiding them. I cannot speak for Symfony and the larger ORM-based frameworks, but I understand the learning-curve to be non-trivial. I strongly suggest staying away from CMS applications like wordpress and drupal as this kind of thing is not their purpose.
I understand that Laravel may offer a reasonably low learning curve and is has the understanding of RESTFul interfaces baked in.
NodeJS
NodeJS offers a very large number of frameworks for the server-side with Express and its variants being the apparent base for many of them. Express offers the flexibility to create RESTful interfaces, but does not do this by default. For more syntactic sugar it is usually necessary to wire up your own middleware.
Ruby on Rails
From what I understand there is considerable support for RESTful apis with rails.
Database support
PHP
Vanilla PHP mysqli Support for databases works, but is too low-level for use. CodeIgnighter, Symfony, Lavel and other frameworks all offer the necessary abstraction and security for working with the database to varying degrees. Differentiating between them on this is largely a matter of taste. PHP frameworks may struggle for support for NoSQL type newer databases.
NodeJS
Express Supports all major forms of databases with appropriate middleware with literally thousands of options from the NPM repositories. As usual, you will have to wire them up to express yourself with varying degrees of difficulty.
Ruby on Rails
Rails supports the active-record pattern which offers both security and ease of use out of the box. This supports the majority of popular standard relational databases. I cannot speak for its integration for NoSQL databases however.
Learning curve
This is too subjective for me to say much other than a few pitfalls: the NodeJS community expects a fairly high degree of skill to get started and the callback hell problem is sufficiently large to be a serious barrier to learner server-side development.
Security
PHP
Vanilla PHP offers little security and is not recommended. Codeigniter, Laravel and the other frameworks offer some protection with string-escaping and protection against SQL injection attacks at least.
NodeJS
Express doesn't offer too many security features out-of the box but can be hardened with modules like helmet. This is not a deficiency so much as a reflection of the unopinionated nature of the application.
Rails
I understand Rails offers basic SQL injection protection through Active Record and CSRF protection among other features out of the box.
Personally: I use Koa (an application to supersede express) for my own server-side dev in working with angular. My legacy projects use CodeIgnighter.
(disclaimer: I'm Ruby on Rails developer)
I believe Ruby on Rails is pretty good to use as json backend.
You can easily found a lot of materials and screencast about integrating it with angular, like:
http://railscasts.com/episodes/405-angularjs
http://angular-rails.com/bootstrap.html
And building proper JSON api with Rails can be helpful for creating mobile app etc, there also very good material about crafting good Rails RESTful Api, f.e.:
https://www.codeschool.com/courses/surviving-apis-with-rails
The back-end is up to you to choose, all back-ends should interact the same with Angular JS its more about what you are comfortable or more experienced with.
You have plenty of choices to look into:
Python: Flask and Django
Javascript: Node JS
Ruby: Ruby on Rails
PHP
Each will have their learning curves and pitfalls.
I'm biased and I recommend Go because it is able to handle huge amounts of concurrent requests and fast (5000 and up) without consuming too many resources.
However jumping between 2 languages can be painful but in the end will give you a broader understanding of programming. So if you'd like not to switch languages remain with the express framework and node.js since that's where also all the tutorials are, MEAN stack for instance (mean.io)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
My company are currently in the process of upgrading their existing ECC6 system to the latest S/4HANA version, and as a result, we'll be looking at developing bespoke Fiori apps once the upgrade is completed.
I read through a number of Fiori development resources online and it appears that a myriad of front-end frameworks can be used; we are not limited to SAPUI5.
Notably, there are several projects which utilise popular front-end development frameworks such as React - which are open sourced and come from SAP directly.
https://github.com/SAP/fundamental-react
https://github.com/SAP/ui5-webcomponents
Having also been to a number of SAP user group meetups, I've had first hand experience at creating OData services which can then be exposed and consumed by the front end. The OData is essentially 'front-end-agnostic' at this point.
I have extensive experience of developing front-end applications with React and Angular 2+ which makes me a little biased but, when we have our system upgrade, will it be best practice to develop using SAPUI5? Are we limited to this? Or is it perfectly fine to use React? Are there any examples of companies/ developers using React with SAP? Does anyone have any experience with this? I'd love some feedback so we can move forward with our strategy.
Please also note that we will be using an on-premise version, with no access to the Web IDE or the Cloud Platform.
To me, it's a no brainer - I would suggest to use React as it's a matured and well tested solution which performs very well and can be scaled with ease, with the addition of easy native support via React-Native should we wish to implement bespoke mobile solutions. Not only that, hiring new developers would be fairly easy and more cost effective as React is more commonly used than SAPUI5 in the web development scene.
Our customers will be the business. To them, the applications will look exactly the same if developed using styled React components vs SAPUI5. The only difference (personally) is that it will be a lot easier to develop via React. Are there any implications of using one over the other?
I know that there are various tools that have been developed in the past for frameworks such as React, which make development very easy. I just don't know of anything that compares for SAPUI5.
Modern frameworks like React also support and follow the latest ECMAScript standards & features - which benefits developers, allowing them to write concise and performant code. State management can be handled with ease, with the aid of Redux and the 'out-of-the-box' React Hooks.
You don`t want to use anything else then UI5 for a SAP system.
Launchpad support, incl. cross app navigation
SAP support (you pay for this already)
Message handling
I believe there is no great frontend oData implementation, except ui5 ones.
Out of the box accessibility features and default translations for a lot of areas(FI, PM etc.)
A large set of enterprise approved ui elements
v2->v4 adapter, you can write now apps for a v2 oData service using the v4 and change once the backend is ready for v4
--
Further more, modern development looks most probably like this:
Frontend development is done while using ui5-tooling
You can use ECMAScript version as needed or include any other tooling
Cloud (nodejs stack) Backend is most probably moving towards CAP
S/4 HANA (ABAP stack) has now a new development model called RAP
S/4 HANA comes with SAP HANA XSA what is basically a cloud foundry environment. Hence, you can deploy almost anything.
All this parts are surprisingly modern and follow the "Zero Lock-In" approach; which means, you could change any of them and still use the rest... but why the struggle. All of this works perfectly together for enterprise use cases.
I can add some extra things:
SAP oData is extended format then odata.org, so it is hard to use it with other frameworks. There is no documentation about it (I can't find it).
Probably your Hana license will be bundled with S/4. So you cannot expose oData from XSA without extra license (Generally DB license limited only own SAP applications such as NW).
Also you can need extra license for consuming SAP Gateway oData service with other frameworks.
Generally SAP license models are very complicated and sales man generally says "Everything included to this license" without unwritten.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We need to implement a one-form app (long form) that persists into Oracle DB. There are no Web services of any kind. The culture is traditionally Java-oriented here but it's open for suggestions.
What are the Pros and Cons of going with:
The traditional MVC Java stack - Spring, Struts2 or SpringMvC, Hibernate
The JS (modern) stack - AngularJS, NodeJS, ReactJS
Any clear explanation of the differences, with the Pros and Cons, would be strongly appreciated.
As I stated, I haven't been able to find a reasonable and understandable comparison.
It's apples and oranges. I'm only posting this as an answer because it outgrew the comment.
First to nitpick a bit, AngularJS is front-end technology, you can use it with any back-end technology (I use it with Struts2). So lets remove that from the comparison.
Second nitpick your comparison is more a JS vs Java choice. If you did your research you could be comparing NodeJS against Play, Vert.x, or similar. Not because those frameworks are "modern" but because they share some of design goals which made NodeJS what it is (Vert.x is very similar in intention, it has comparable speed, non-blocking design, and allows for polyglot programming).
But really there is something more fundamental than the frameworks... and that is the language. If you know JS and you've worked on the front end design did a mockup and then need to develop server side services and aren't more comfortable with another language, well it really doesn't make sense to invest in that heavy lifting when you can start doing something useful right away. It's also the same the other way (from the Java perspective) no matter what the framework you need to invest time, if you already know a Java web framework, why waste your time figuring out something else?
That last question isn't rhetorical, seriously why waste your time? In defence of keeping with JS, you can keep everything in one language, NodeJS is pretty fast, although keeping the comparison fair there are many Java web frameworks Struts2/SpringMVC don't have similar design goals to NodeJS while Play, Vert.x, and I'm sure there are others would be a more fair comparison. JS has a different way of doing things and if you have JS ninjas then it does make sense to do everything that way. As for why Java, it is fast, it has an enormous codebase, there are APIs and frameworks for everything, from meta programming, AI, robotics, security, obviously databases and everything common, there is enormous choice. It is more structured, in the end this means that months later you can generally figure out what you were doing and you can better share work and divisions of labour. But again, does any of that matter? I'm not looking to start an argument with the general public, only you know your requirements. Consider them and also consider human nature and take a reasonable course.
In my experience people use what they know, people I find are often splitting hairs over their favourite framework and someone else's for no other reason that that is what they know. If you're going to use some technical tooling advantage to try an get consensus that is highly unlikely to happen, and I would recommend first to look at your human resource capabilities; I mean you could write it in Java or JS, whatever but happy employees will produce way more regardless! What the majority would rather work with can't be discounted lightly.
This is not a question which stack you use. Pros and cons have nothing with the technology involved rather than humiliating the user experience by choosing one framework over another.
If you get any project from an idea to the production software you should know that many many, many factors apply on making decision on the architecture of the project. All it depends on the proposal that you should write first. The quality of this document will make influence on the further decisions and directions, feed-backs from the end user who is the consumer of the desired product.
No language, no framework, no programmer needed to provide you the user requirements. It's just the software that should do some things. That's all you need to know at the first time.
You can promise the user that you can build the software that is required, but you don't tell how it would be built, which language you use, framework, technology, resources.
You can see what other people is created and how it works and if it fits with what user is required then you luckily copy/paste. Unfortunately, it doesn't work in most cases and you have to pay for every brick in the building.
The most significant part over technology is programming resources. If you have such resources that you already tied a half which technology is preferred to use with the project. Technologies, languages, frameworks are different, and nobody can handle them all with expert level. You can build the software with one framework, then rebuild it from scratch with another and then you can compare. If you can't compare the costs used to build the software than your decision is just opinion based on other opinions.
The pro-vision occurred if you have experience of building production software on different platforms using different languages and different frameworks. Because many languages, frameworks are in most business problem oriented and recommended to use by experts as suitable to solve such kind of problems. There's no any point which one is better, because if you choose one that is more recommended than others and create ugly software using it you can't say that it's worse that others that are less recommended. On the other hand if you choose framework and create the great software that may be lacks some features available in other frameworks you'll win.
Don't play with the technology, use qualified consulting services. This is out of the topics of stackoverflow. Because this information is always commercial. Good luck with your endeavors to find the better software that suits your needs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have tried this tutorial:
http://kodeinfo.com/post/realtime-app-using-laravel-nodejs-angularjs-redis
which in short is building a real time app by using Node.js + Angular + Redis + Socket.io + Laravel (PHP as a backend).
The question that is bugging me is why try to leverage all of these technologies just to implement a real time feature? Are there any more benefits to using this (Node.js + Angular + Redis + Socket.io) stack over, lets say, simple AJAX call to the backend? For what other use cases you have used this stack?
Each of the technologies you've listed is not required for real-time, however I think you might find it useful to get further understanding of each technology and it use.
Each technology has it's advantages and usages. I would suggest you do some more in-depth reading on each technology separate. You can always use just ajax but you're missing out on a lot of the advantages of each technology. All of these are highly tested, DRY and componentize, meaning you'll prob be productive quicker and re-invent less of the wheel.
Furthermore these technologies tend to work really well together, and are based on many similar concepts.
Node.js - you'll need some backend technology for sure, you can use php, node.js or whichever you prefer. However node.js has some clear advantages.
Aside from being JavaScript, so you can share code, and node.js non-blocking i/o allowing you to use more resources.
Why use node
Top 10 reasons to use node
How to decide when to use Node
Angular - angular is your front-end mvc. There are many frameworks (Ember, Backend and many others). you can pick anyone or pick none, however this does not replace AJAX. Their framework bring loads more such as two way data-binding, components, data layer and so much more. again great building blocks to build a high impact professional app.
Why use angular
Three reasons to use angular
what does angular do better than jquery
Redis is a nosql database. Real-time has very little to do with it, however it can be used for that. However it has been used for many pub-sub implementation to maintain state across instances / clients. Have a read about Redis
What is redis and when to use it
why is redis ecosystem flourishing?
Socket.io - This is the most real-time oriented component and the main one you might actually "replace" with Ajax. I would strongly urge you, than even if you decide not to use any one of the other component, you still use socket.io/another socket library. Socket.io provide browsers / servers with a socket like interface (similar to winsock on windows). Meaning browser can send and receive messages. Just FYI socket relies heavily on Ajax, however it simplifies the usage and does not require you yourself to main the connection state, handles browser inconsistencies and much more. While you could potentially write faster code using plain Ajax, more chances are you'd end up introducing more issues...However it's your call :)
Why use socket.io
Ajax vs Socket.io performance
My team is developing a Java web system using the Play framework and implementing Angular.js throughout. My question is, should I use Cucumber-java or Cucumber.js for automated BDD functional testing? What are the pros and cons of each when using them against this technology stack?
I've found very little online about which to use with this particular technology stack.
Firstly, the Cucumber is designed as a collaboration tool. If you're looking for a test automation tool, then you're probably best off choosing something that doesn't add the overhead of devising and maintaining a plain-English, ubiquitous language.
If you are collaborating with non-technical stakeholders, then Cucumber is a good choice. The whole team will collaborate writing the scenarios, but it will be the devs and testers that write the 'glue' that links the scenarios to the application you're building. If you choose Cucumber-JVM you'll write the glue code in Java/Groovy (or other JVM language); if you choose Cucumber-JS you'll write the glue code in Javascript. So, one of the questions to ask is "what language will my testers and devs be most comfortable using?"
You'll probably mostly drive your app through an interface that it exposes(e.g. the GUI or a published RESTful API). Whichever Cucumber you choose, your 'glue' code will use some other library to interact with your application (e.g. Selenium WebDriver), so another question to ask yourself is "are the libraries I need available for Java or Javascript?"
Sometimes you might want your 'glue' code to talk directly to your application code. Cucumber-JS 'glue' can easily call Javascript directly, Cucumber-JVM 'glue' can easily call Java directly - so that might affect your choice. Remember, though, that only a minority of your scenarios will normally bypass your application's interface, so if this is your major stumbling block, you should revisit your approach to BDD. Some of these tradeoffs are also discussed in these slides
Finally, my feeling is that Cucumber-JVM is currently more mature than Cucumber-JS. Aslak Helesøy and Julien Biezeman are founders of Cucumber Ltd (along with Matt Wynne), so I expect them to reach parity at some point. For more information about Cucumber take a look at their online videos or <personal_plug>buy The Cucumber for Java Book</personal_plug>.
Before signing a vendor-lock from the open source perspective I would compare:
number of open issues, the less the better, no serious issue should be left open for years
number of unapproved pull requests, the less the better, no request should be left pending for months
what the key developers say about their product
your estimated technology learning costs
...?
Cucumber-JVM
Issues: GitHub: /cucumber/cucumber-jvm/issues
Pull requests: GitHUb: /cucumber/cucumber-jvm/pulls
Heroes: GitHub: /cucumber/cucumber-jvm/graphs/contributors
→ Aslak’s view of BDD, Cucumber and automated testing, December 12, 2014
Cucumber.js
Issues: GitHub: /cucumber/cucumber-js/issues
Pull requests: GitHub: /cucumber/cucumber-js/pulls
Heroes: GitHub: /cucumber/cucumber-js/graphs/contributors
→ Cucumber.js for BDD in JavaScript: An Interview with Julien Biezemans, April 15, 2014
User's voice may be also a good indicator but that would fall into the site's off-topic category
primarily opinion-based
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I apologize in advance for the open-ended question. I tried searching, but wasn't sure what specifically to search for, in all honesty...
Briefly put, I'm a novice iPhone programmer and I've made applications that have communicated with a Java server. For example, my iphone application would use HTTP Get or POST requests and would receive back data. However, I'm not the person writing the server side code and frankly, have no idea how it's done!
I'd like to learn at least the mechanics of how things are done on both sides, so now I'm trying to learn. I picked up a book on Google App Engine since it seems like an economical way just in case I do decide to release a server/client app.
However, I assume that I could have chosen RoR or PHP as well. I'm assuming the principles must be the same.
If anyone could point me towards tutorials that shows the "other side" of what happens in a server/client app, that would be most appreciated! By other side, I mean, on the client side, I already know how to request and receive data. I just dont know what happens on the server side...
Thank you and sorry for the general question..
These are most important components of web application:
an http server: serves static files, works as a pipe to your applplication for dynamic content. For example: apache, nginx.
An actual web application: handles requests for dynamic content. Usually you use a a web-framework. For example: django for python, symfony for php, RoR for Ruby, node.js for javascript.
A database server. For example: MySQL, PostgreSQL
Some other things which might be considered:
a mail server to send email messages
image processing libraries
fulltext search engines
These components are less common:
memory caching server, for example: memcache
non relational databases, for example: redis, couchdb, riak, mongodb
task queue server: for example RabbitMQ
The reason why appengine might seem easier for novice is that you don't need to configure web server or database. You only need to write your application code. Fully-managed hosting with task queue, memcache, datastore, content-delivery-network are already available in appengine.
The problem with appengine is that it forces many limitations on you.
If you don't need memcache, task queue and distributed system then it is very easy to develop applications with popular frameworks, they provide tutorials how to set up your own http server and database.
If you need these advanced parts then it will be more difficult to configure everything.
Common practices in web application development include:
using ORM to work with relational database
using MVC or similar pattern to structure code
Html code is kept away from code in templates. Thus templating language is used.
As a web-backend developer aside from coding application code you also need to understand well the database which you use.
If you only build a backend for your mobile application, you won't need HTML, CSS, Javascript and templating. Though MVC pattern and ORM still applies. You also will need to know more about HTTP protocol and various methods of implementing an HTTP API. If you like XML, the WSDL does a good job. There are great libraries for WSDL which makes writing HTTP API easy.
The base API in Java is the Servlet API. Read this tutorial.
On top of this API, there exist a myriad of frameworks (Stripes, Spring MVC, Struts2, JSF, Wicket, etc.), which all have their own philosophy. There are two groups of frameworks, though: action-based ones (Stripes, Spring MVC, Struts2, ...) and component-based ones (JSP, Wicket, ...).
The action-based ones usually use JSPs for their view technology (to generate the markup), but also support others. What you'll learn if you learn JSP will be useful in a variety of frameworks, so I would learn it as well. Read this tutorial.
I applaud your choice of starting with App Engine:
Some concepts of GAE are hard, but so is SQL. If you don't know either you might just start with GAE which is a modern noSql system.
GAE is not a good fit for all problems. But I believe it is a good fit for your setup: a lot of independent clients with limited need for heavy queries.
About the cost: GAE is cheap if you know how to programm it. I have both EC2 and GAE in different setups, and while they are hard to compare, I believe GAE is cheaper.
IMHO most of the cost of hosting comes from support/management cost. We have a team 10+ developers, but no system/database admin.
I think, starting from app engine may not be good idea for starter for server side developing.
Asp.net ( or php) will be more "efficient": not only source for learning and tutorials but also better for make mistakes and learn better
Once you done with asp.net, and have good pratice about your server side project,
it is easy and very fast move to app engine
good luck