I need to build an application that mostly displays grids of DB information, and drill down edit forms. It has a few "analytics" on it, but nothing fancy. The application must be multi tenant and hold a load of a few thousand concurrent, external users, that authenticate using SSO/JWT.
Is the Microsoft power platform a viable platform for this type of solution?
Thanks.
Building such kind of applications is the main purpose of Power Apps.
Build apps in hours—not months—that easily connect to data, use Excel-like expressions to add logic, and run on the web, iOS, and Android devices.
Related
I have a project in mind for a desktop aplication that interacts with e-shops directly. My goal is to create an application that uses the e-shop´s table and presents it to the shop through this app.
Before I get too into it I want to find a shoping cart software (preferably the oneclick installs that many webhosts offer) that will let me access it´s tables and modify/read/write at will without going throught the website.
Could I do this with OpenCart?
if not which way should I shoot?
Thanks in advance
Normally this is not possible unless You'd stick directly with some DB administration tool that will connect directly to the database server. There are some options though:
write an API for the desktop application - it could be based on web services - that the desktop application will comunicate with (more work has to be done but this should be the best solution)
let the desktop application connect directly to the database server (the same settings as OpenCart uses; requires only the desktop application development)
or as I mentioned, use a desktop DBMS tool for MySQL (or one that is universal), there are plenty of them, many also free... (no development at all but I'm not sure if this would be the desired solution)
I have a specific question about Java EE architecture. I have an application that requires several components:
A web service and persistence layer (cxf/hibernate)
A management / configuration console (Struts2/JSP?)
One or more user "applications" (Maybe Vaadin?)
Note, the web service will provide services to the user applications.
The web service has been built as a cxf/glassfish application (Eclipse dynamic we app) and is working well.
Should the management and user applications be developed as entirely separate applications (EJB's or ?) or form part of a "single" application with the web service. I am not sure if I am explaining this well enough - but I am new to this sort of design and am trying to approach the solution in a well structured way. For example I could imagine that taking an approach of separate services (applications) could result in:
Primary web service (does common data persistence stuff)
Authentication service
Management App service
First user App service
Second user App service
Each of the user apps is likely to have both common and unique data persistence requirements.
To decide how to split your implementation, you should consider your system through different views. In software architecture, there is a very useful method which is called the 4+1 architectural view model (http://en.wikipedia.org/wiki/4%2B1_architectural_view_model). Using the Physical view you will be able to decide if you may need to install the different components in different machines, and this will help you to define your development view, that will give you the answer to your question -> how to split the different components of your system in a development point of view. Once you have the development view, you can define how the components communicate (process view)... and so on.
This views have always helped me, I hope you find it useful.
I am having a desktop application which having a UI interface made in Qt linked with a library which is doing all the calculation stuff. Values from UI is taken and pass to the API's in the DLL to get the output which is shown on Screen.
Now i want to do the same thing by transferring my application UI to a web page so that people can access the tool from anywhere without any installation process.
I want to retain my c++ DLL code so i don't have to do a lot of work. I am thinking of just converting this DLL to a C++ server by any communication Process(Sockets). I want to host this application on my company's website. (We have to make the website also so we are open to any set of tools).
I want to know what will be the best set of tools to do this stuff. Also there will be lot of data exchange between the webpage and server so the wholething should be optimized also. I goggled a bit and find stuff like silverlight and ASP.NET, But i am still not very clear which option will be more suitable.
I am a c++ programmer with no web application development experience. I am open to learn any new technology.
Thanks
Why not use Qt on the web directly? There are several projects like this one: http://qtwui.sourceforge.net/
There is a netscape plugin that will host a QT application and an ActiveX control wrapper on the QT website. You could use one of those to wrap your application. Note that this approach would require the user (or their administrator) to download and install the plugin.
An alternative approach might be to run your application through a remote desktop such as XVNC, NX or an RDP based layer. IIRC browser based remote desktop clients are available for most such protocols.
A few options:
pick a messaging/queue implementation (like http://www.zeromq.org/) and provide a service
implement a Windows Web Service if you want to be more enterprise friendly: http://msdn.microsoft.com/en-us/magazine/ee335693.aspx
I would not expose the implementation on the internet. Enough to have a simple buffer overflow and the machine can be taken over quickly. Adding a layer between the app and the web provides an easy way to validate input, access, stats ...
You should be able to use your DLL from an wt or cppcms application. Then you do not have to learn something new and can just use C++.
The way I'm currently doing this is with Boost.Python + django
I work at a company with a large SAP investment, and we also have dozens of large .Net systems (mostly internally for engineering systems), and Java platforms (mostly for external web applications). As such, we have large development shops on ABAP, C#, and Java EE.
We have decent standards for which platform to use in which domain, but we don't have a lot of clarity around when to use web UIs and when to use desktop UIs.
I've seen some excellent research on this topic in the past (like this), but I'd like something a little more structured
I'd like to build a decision tree based on best practices to help with this question.
Some of the criteria I've seen in the past include:
Is the application targeted to users
with different OS configurations?
Does the application require OS-type
functionality for sorting and editing
data? (I know that AJAX /
asynchronous JS has made possible
much richer desktop-like
functionality to web applications,
but some would argue the desktop is
still king in this area)
Will a web application be able to
provide the availability,
responsiveness, clarity, and utility
that can be delivered with a desktop
application?
I think we are seeing the separation between Web and desktop applications softened quite a bit. Rich internet applications (with Flex, Silverlight, Ajax) started this trend, and WPF with XBAP is taking the user experience of browser-based applications to another level.
It is becoming a bit more involved to have this argument, because there are now more flavors in the spectrum between Web and desktop apps.
Some more questions to ask:
What is the primary objective of the app - data manipulation, or data viewing?
What is the number of data points/records that need to be viewed/edited together on one screen?
What is the organization's IT infrastructure look like? Will they be able to accomodate new deployment models?
Will users work with a central database from remote locations?
Does the organization have a VPN infrastructure of off-site users, and how do users authenticate?
Are there existing applications that the same user group is working with, and how are these applications deployed?
Does the application need offline capabilities?
Given that they are so different, what is the skill set of the development team for web and desktop APIs?
I've been asked to build 'widgets' that let users of a web application install a desktop, or web-based widget which will provide:
Notifications of new content.
Personalized access to key performance indicators
I'm looking for some information to inform our requirements and design discussions.
On the desktop you can target the Vista Sidebar, or on OS X there is the Dashboard, as well as others. From the web perspective you can target iGoogle and others. If I was to start by developing for the widget framework that had the greatest number of users, which would I choose? Does anyone provide statistics on the number of users?
The client would prefer to provide a richer experience for end users and I think this could be achieved using a desktop widget framework. However there would be some questions around the number of users that we can hit with any single framework (eg. sidebar). What technology or framework could I target that gives me cross-platform compatibility? Should we embed Flash?
Rather than live within a widget framework, I was going to suggest the creation of a standalone application. Are there any frameworks that help facilitate the creation of widget-like applications?
Target platforms:
Windows (Windows XP and newer)
Apple (OS X 10.4 and newer)
Linux (nice to have)
You can put a glance on Adobe Air.
It allows a cross-platform development in Flash/Flex or HTML/JS.