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.
Related
For my company, I'm attempting to determine which of many mobile hybrid technologies we want to use going forward. If it matters, typically between 1 and 4 developers work on each project. We currently have about 10 mobile applications, and we plan to expand on many more.
Currently, we use Sencha/Ext for our "front end". We package with Cordova/PhoneGap to iPhone and android phones, with a MobileFirst back end to handle sessions, and auto-updates.
We'd like to replace at least the cordova and sencha part of our technology stack.
My question: Is it possible or even wise to use simple angular with react-native-renderer to create hybrid mobile applications?
Or, is it better to use a framework either separate from angular (e.g.: React Native) or in addition/built on to angular (e.g.: Ionic)?
My feeling is that using react-native-renderer with simple angular code will not provide us with many helpful features that the other platforms use. But I'd like to get insight from the stackoverflow community on this.
Thanks.
The answer to your question is yes - it is completely possible using the renderer you mentioned to utilize both features of both React Native and Angular to ship a hybrid technology. You are basically getting a React Native application in which an Angular 2 application runs in the JS thread with a custom renderer that uses the JS APIs to create a native UI.
But is it wise or a stable long term solution? The answer to that question is definitely no! This is essentially gluing two different technologies together which are both in developmental stages and will present plenty of bugs and difficulty in completing and publishing your apps unless you and your developers are very fluent in both angular and react native. Almost always it is better to stick to another framework entirely and in the future possibly integrate angular again.
Side note - run from Cordova/PhoneGap - it is not the smartest choice for any stability or consistency in development. User experience is also a downfall plus there is also serious doubt in how much longer it will be updated and maintained
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)
I'm trying to develop a hybrid app which will deliver a range of simple teaching material to the user. I am planning on using Telerik App Builder in conjunction with Cordoba 3 to create the app. What I cannot decide is how best to package the actual content into the application. I'd like to achieve a separation of the content from the code, and just combine the two when building the delivery packages. (The content is being prepared by a subject matter expert.)
Is there a way I can use Cordova or Telerik AppBuilder to pre-populate a SQLite database as part of the app install process? Or am going about this in completely the wrong way? I have been researching this in the Telerik documentation but without success so far. If someone could point me towards a suitable example or even the correct places in the Telerik or Cordova docs I'd be very grateful!
I recently ran a techie webinar on the topic. The main idea is that you need a centralized system to host this content and this system needs to expose some kind of a service layer that will feed content to your app. To me this seems like a very growing market opportunity, but feels kinda the same as the web 1.0 days where all of us were trying to figure out how to feed cotnent to websites and everybody was building their own CMS in a way.
Telerik Backend Services provides an editing interface, so it can fit some requirements, but it's not a publishing system, plus you may not want to pay developer licenses to your back-end users or provide them with access. The premise of the webinar I am talking about was that we discussed how to integrate with another telerik product - Sitefinity to do this job for you instead. The first 20-25 minutes are an overview of the platfrom, so if you have seen it already, you can certainly jump to ~;0:25 to see the rest
http://www.sitefinity.com/campaigns/webinars/build-content-driven-mobile-apps
Now certainly it doesn't have to be Sitefinity or CMS for that matter, Sitefinity provides a bunch of App Builder related features that are handy, but you technically have a few options:
- Build your own applicaiton and back-end.
- Use any type of CMS or platform that will give your SMEs the back-end interface to publish and the service layer to expose to the app. In the webinar I also go through some neat tricks such as using push notifications upon publishing.
This way you get a clear separation of content and code - you can even get a separation of content structure and code, which is an idea i talk about in greater detail.
I hope this helps!
Svetla
The GWT page on the Vaadin website is a bit sparse: https://vaadin.com/gwt
"Only benefits, no gotchas
You will enjoy everything you love in GWT and get the additional benefit of a novel server-side programming model, components, tools, themes and other extras. If you do not like what you are seeing, it is easy to return as long as you stick to using com.google.* packages. You will probably be tempted to start using features in com.vaadin.* packages eventually. But there is no need to worry—Vaadin Framework is also distributed under the same liberal Apache 2.0 license"
I like some of the look and feels on the Vaadin website, but I'm nervous about "server side models"... I would rather have most of the code running on the clientside if at all possible, and I'm checking GWT RPC calls again (often with the same java code) for security. I don't like the idea of lots of back and forth.
Given my concerns, is it worth digging deeper into Vaadin? Or do I stop here? Can I leverage the various look&feels without stomaching everything? Any other non-intuitive answers about leveraging would be appreciated.
UPDATE:
Please don't answer the question comparing Vaadin vs GWT, offering alternative UI frameworks.
I've also used SmartGWT, GXT, and bundled GWT widgets etc. Also familiar with some really complete widget sets like DevExpress for .NET . The reason I asked the question is because Vaadin LOOKS really cool... I'm looking for answers like : No, it's not possible to extract the L&F from Vaadin without compromising the clientside OR besides the L&F stuff, there is cool validation stuff etc etc etc which you can use, and then perhaps some useful evidence to back up that position (tried and failed).
I am answering only a part of the question about the L&F i.e GUI and Security.
1) L&F
Vaadin upto 6.x release does not support independent use of widgets. You need to get into the whole server side models.
However, from version 7 onwards Vaadin is leaning on spinning of Widget side to allow widget use without being forced to use the back/forth jsf like server-side state maintenance.
Reference - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/3U1h0W_iHcM
2) Security
GWT side has pretty nice support with XSRF feature for RPC which would allow rpctoken generation per RPC call or selectively with your choice of granularity. This be might be a performance overhead for Vaadin roundtrip per sever-side-state call.
3) GAE is a factor depending on how heavy your Vaadin roundtrips really are.
4) Future
Vaadin is a member of GWT steering committee and along with Jboss Errai (asynchronous bean management in Errai roadmap) lean heavily on server side models.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We're the developers of a relatively complex non-game iPhone 3 application, and we're beginning an ambitious rewrite to take better advantage of iOS 4. There's a significant social element to the app, so we started thinking that we'd like to make it available on as many modern mobile platforms as possible:
iPhone/iOS
Android
Windows Phone
BlackBerry OS
Symbian
There are several approaches to cross-platform development, and they all have limitations. No solution manages to take advantage of all a device's functionality the way a native application can. Given the complexity of our app, I'd simply like to maximize "logical" code reuse without resorting to a cross-platform framework. I'm envisioning tools that will make developing and testing apps against multiple platforms a little more seamless. What can we do to make developing on 5 platforms take less than 5 times the effort?
Push as much of the functionality as you can back to a shared web server, and try to make only the UI specific to the platform.
I know you said no cross-platform frameworks, but perhaps something to look at:
Write all the core logic in javascript. Unit test that at will. Then use tools like Appcelerator to turn that logic into native code.
Then import that logic code into your native platform projects for each of those platforms, and build out the other features you feel can't be achieved properly in any other way.
For platforms they don't support right now, you might be able to find a js to native code converter, or indeed a way of hosting a js environment within those platforms.
None of these will play nice together. It's not in their perceived best interest to do so.
The best bet is to dumb everything down and keep it simple. Simplicity always wins when you are trying to sandbox multiple hostile interests.
Look to XML for all data, and then have 5 binaries to read it or push it all to a web server via PHP. All these mobile platforms will function nicely with XML because it's in their best interest to do so. Worry about branding and appearances AFTER you get the core functionality off the ground.
NOTE: Javascript is the last thing you should be looking at in the beginning. It rarely plays nicely on all platforms in the same way. So make sure that your JS layer is independent of your data layer. DO NOT INTEGRATE THEM. That would be bad. You want your Android JS to be potentially different than the JS you push on the Blackberry for example. Because you won't know how quirky it will end up being until you try it out and test your methods.
I agree with Beth. I have developed a product based on the same thought process. I have a java server running on a socket, which has a client library that client app's use to connect to the server. The client abstracts out the socket piece and provides easy api's for client apps to call.
The server is equipped to handle multiple client connections in parallel, thread pool concept.
Now, since it will be a java client library, you can only run this on android. To get this working on other platforms, you can run this client piece on J2EE. This way you create a third middle layer. All other platforms can then connect using the browser.
With this done, you can now use JSON to Object libraries to expose your object (on the server side) to JSON. I haven't done this yet, but will do it in a few weeks.
Btw, I just cant get myself to use any cross platform frameworks. They promise the world, and dont mention any of their limitations upfront. Its painful towards the end of your product/app release to find out all these limitations/hidden costs.
Well, you can look at JQTouch, SensaTouch or maybe wait for a while to see the jqueryformobile to finally get published. If you are not in a hurry, I would already start working in jQuery, since two out of three from this list are (will be) based on jQuery as plugins
I'm currently thinking to this problem , and my solution would be to put all the logic server side and use an approach like Model-View-Presentation, a series of events fired by the UI that should instead be specific for the client