Are you saying your SPA's talk directly to the DB ? Not sure I would be
advocating that.
You need some sort of server side code to interact with the DB unless you
know something I don't :-)
I just returned from our monthly meeting of Utah IBM i Professionals
Association (UIIPA). We started a Linkedin group under the same name, and a
sub-group named IBM i Application Modernization. A few members plan on our
first GotoMeeting, which is scheduled in the afternoon of June 3, 2015 to
discuss this type of application architecture and review some tooling which
one of our members has been working on.
We're just getting the group started; there are no current discussions. But
we plan on discussing "modernization, from A to Z" over coming months. Feel
free to join the group for announcements and further discussions.
Regarding SPAs talking "directly to the DB", for me that conjures up images
of clients "injecting" SQL and performing DB I/O with few or no security
constraints; the kinds of things that most ASP.NET applications do. No, I
would not advocate for that.
The problem would be even worse to provide unconstrained or insecure
interfaces to client devices, because it is so easy for client-side tooling
to monitor network communications, mimic browsers, and commandeer REST
interfaces.
It appears that Kelly may have been reading my posts more closely, and
gaining a picture of a utilitarian interface (requiring little or no
server-side programming), but still enabling SPAs access to IBM i
resources, to perform DB operations, by using an interface which is more
secure than say a .Net data provider.
If I understand correctly, you created an interface between .Net and
XMLSERVICE, which provides for IBM i SQL injection and program calls.
XMLSERVICE in that context is a "utility". I'm talking about a similar
utility, which includes finer grained "authorities", and which prevents SQL
injection.
midrange.com
