Let's follow up this discussion at the Neptune Community
(this forum will be kept in read-only mode)
Now Njål Stabell has posted about this on SCN: Three Major Misconceptions of SAP Enterprise Mobility.
Here is the passage:
"3 – Base your Enterprise Mobility implementations on an API first approach.
The API first approach is gaining momentum. Theorists (I’ll pay for this ) claim that it boosts development productivity and helps create multi-platform applications more easily. A few years ago, we had the same hype around the ESR (Enterprise Service Repository) and SOAP was the solution for all integration and external exposing of backend data (I returned to good old custom IDOC’s after a short time). Well it was not. Our PI systems crashed and debug was hell. Why? The services were created for certain scenarios and often complex and not optimized for large volumes. Today we look at oData through GW services, often with nested structures demanding complex client-side logic and low performance. Performance is vital in a mobile scenario.
Therefore, it is better in my experience, to create your backend access in parallel with client functionality – Consumer first approach. This will ensure that you only fetch and send the data you need in each request. This (And superior offline capabilities) has been the main reason we use native JSON bound to element attributes in the Neptune Application Designer and not taken the GW path, even though external pressure has been big."
Hope that clarifies things, Mark.
thanks for clarification again.
But customers have to support oData on their way to HANA and in this context Neptune becomes a growing disadvantage during presales and projects with this strong denial of oData.for this point of view Neptune isnt big enough to resist against SAP (my personal opinion).
On mobile scenarios i am always with you. but we build webapps for online scenarios too an if customers have to build a given odata structure with integration by their own into Neptune app customer gets more and more annoyed about this topic.
customers have to support Fiori and Neptune in parallel - but i may not lead into a divided app world: one with and one without oData - then Neptune will loose.
but if Neptune supports oData, we could build apps which can be easily transferred later on HANA without adapting any dataretrieval - this would be avery great argument to build apps with Neptune today.
best regards Ralf
First of all, thank you for the feedback. Our hope is to make this forum and our community in general more active so replies like this is great.
Let me clarify a couple of points regarding Neptune and oData and HANA.
HANA you do not need oData for accessing a HANA DB. CDS views and even accessing data from SAP Cloud Platform's HANA DB (Formerly HCP) is performed by loads of our customers and partners.Remember that Gateway also is an ABAP solution and uses ICF for communication, so everything you can do with GW you can do with Neptune ;-)
Finally, we at Neptune are strong believers in simplifying the development process and we see that modern agile development methodologies are more easy to use with our low-code single developer approach with consumer-first instead of API first which in many cases forces you into waterfall like methodology and increases development time drastically.
Anyhow that was my 2 cents
Just wanted to add my 2 cents :)
In the following demo Neptune App (links below) you will be able to compare:
Preliminary results (from my slow home connection):
Please feel free to test and play with the app and share your conclusions.
Wow, looks like AppSync is a factor of 2 times faster with less transfer to boot.
Well done Julian :-)
Sorry guys, but what are we talking about: a mobile app or an interface?
I think we are talking about a mobile app and that's why we shouldn't use unrealistic amount of data for the measurement.
20k rows of database lines? Let us break it down to 200 rows (else the design of the system is wrong), so a factor of 100. And now we have an answer (or better transfer) time of 61ms with OData, 48ms with JSONH and 20ms with AppSync. As a user it is more than irelevant if he's waiting 60ms or 20ms.
Concentrate on the usability / design and use as backend what ever the system provides. CDS views -> OData ftw ;).
Nice to see you here.
The 20k size is for our offline apps. And this is even small amount of data in a typically Neptune offline app.
I don't think we need to discuss what protocol is the best oData/Neptune JSONH. In the upcoming release we will add full support for oData. Then it's up to the developer to use oData source(s) or/and the Application Class. I do see the benefit using all the strengths of oData with Annotations and CDS Views !
Disclaimer: this is under development :-)
Just wanted to clarify 2 important things:
A- Last Thursday and Friday, the Odata service was fetching only 200 (instead of 20 K ) records. If anyone has been playing with the comparison tool, they would have gotten extraordinary good results for Odata performance.
B- Besides this really interesting discussion about performance and data usage, an important thing is that Neptune UX Platform SP03 is introducing support for OData services :)
Do I understand this right:
>the Odata service was fetching only 200 (instead of 20 K ) records
The results of your speed test above are based on just 200 records, not 20K records?
That would be marvelous.
If yes, please update your original post, if possible.
Love that you guys have listened to the community feedback and
If anyone reading this has experience with OData and a has vision on how to ideally support it within the Neptune platform, now is the time to step up and help make it the best it can be. Let us know, Mark.
No, what I mean is that the results of the test posted on this forum topic are 100% accurate.
I was just saying that "in case someone ran their own tests last Thursday and Friday", the results they got were not accurate since the oData service on our end was only retrieving 200 records at that time. This happened only last Thurday and Friday.
All kind of suggestions for making the best oData support are extremely welcome !! Thanks !!