I'm starting a Flex app on a pretty big reporting engine and want to know how best to connect to a Postgres Database. I'd like to create a REST API architecture so I can use the service for more than just the Flex app(mobile possibly).
These are my options I've found:
Datatype: either XML, JSON or AMF
Flex Service: HTTPService or WebService
Server(using PHP): ZendAMF, custom json_encode implementation, Zend_Rest_Server
I've got my views all mapped out, and the api functions designed. Basically what I need is advice on which Flex / back-end service combo to provide.
Thanks for the advice!
Best service/connection combo for Flex/Server Implementation
There is no best way, but actually depends upon your project and how would you like to proceed. There are three ways.
Remoting
HTTP Service
Web Service
Since you would like to re use those services in other applications too, i would suggest you to go with Web Service. You can create your Web Service using any Server siding language which you prefer and communicate it with your Flex Application.
Regarding AMF
Its one of the ways how you can interact your Flex App with Server siding language. AMFPHP or ZendAMF does a good job and its so easy to communicate.
I would suggest you to concentrate more on Flex Architecture rather than looking into how your Flex is gonna communicate with Backend.
Check out for Modules based Architecture.
Check for which framework you are going to develop your Flex App. [ Mate, Cainogram, Swiz or someother] When you have decided with your frontend Architecture on how the flow should happen, you can then decide on how to communicate and which is the best possible approach for your project keeping the future things in your mind.
Since your Application is going to be reports oriented, go for Web Service.
[I] want to know how best to connect to a
Postgres Database.
Best is very subjective. You probably don't want to connect to the Postgres database directly from Flex. Flex is not designed for such things. I recommend using an application server as middleware. ColdFusion, .NET, PHP, Java, and just about any other 'current' application server can be used as that middleware. I would recommend using whatever you (or your team) is familiar with.
For Flex, I strongly recommend you using an AMF implementation. AMF is a binary format and will give you smaller data transfer packets, plus server side object to client side object conversion. It'll save you some time writing XML parsing routines, which can be annoying at times.
With ColdFusion, it is pretty easy to create a server side service (CFC) that can be used for AMF, SOAP Web Services, and REST services all at the same time. You just specify 'access="remote"' on the function definition. I would expect other server side languages have similar functionality, but never investigated the web service related features of other languages.
Related
Using Laravel for PHP and DBMS. How do I make an app? (for social networking).
I have googled most of the things but I am really an Amateur and need help.
There are many kinds of apps, so before you start to work on your app, you need to carefully determine what exactly you need. You could write desktop apps for various operating systems, or native mobile apps, or hybrids, or a web application... You name it. Anyway, Laravel is the server-side and it should be as agnostic to the apps as possible. You need to create an API and handle the following things:
CRUD for the database
session (log in, log out, register, password change, user settings)
logical API functions
file transfer protocol usage
push notification (if needed)
As per your requirements, you will need to implement the server-side API in Laravel, which is a PHP-based framework and use an RDBMS, which could be MySQL, SQL Server, Oracle, or a NoSQL database, for instance MongoDB.
Before you implement any apps, you should have a proof-of-concept for the API. You should not invest too much time working out the details of the API, as when you are going to work on a real app, you will notice things to be changed anyway. The API should be accompanied by a playground for testing, maybe a very small app without design where you could send requests to the API. Or you can implement a WebSocket API to have a single, duplex connection. It is up to you.
As about how to write an API, there are many tutorials.
Does Google Chrome web store support server sided technologies such as PHP or Python?
I am currently making a productive web application which i have already implemented in python but i wish to give it a nice little web application interface and also harness the power of PHP...
Does Chrome support Python or PHP; or does Chrome even support Server sided scripting?
I am learning how to develop chrome apps from here...
If a member is aware of any better tutorials please inform me...
Or is it that i just have to build a normal web applications and add a logo and manifest and zip it and publish it?
Thankyou...
The platform supports server-side technologies the same way a C++ or Java application would support them: through HTTP (probably RESTful) interfaces that the server side of your app (if any) exposes. For example, your app might make a request to http://example.com/api/foo/bar/baz?param1=123¶m2=456, and might get back a JSON response that your app would then parse. It doesn't really matter which server-side technology you're using, because the API looks the same from the app's perspective.
If you're asking about PHP, Ruby, Python, Go, node.js, etc., running on the user's machine as a client-side app, no, that's not how Chrome packaged apps work (though in theory one could get one of those environments running as a NaCl module that then generates client-side code). Instead, you write code in a very similar way to how you'd write a pure AJAX app: in JavaScript, without navigation, with the content/data being fetched in a RESTful fashion from whatever server/service you use (or none in the case of something like a calculator or simple game that doesn't talk to the network at all). Incidentally, we're finding that very AJAXy apps are relatively simple to convert to packaged apps.
Check out all the samples at https://github.com/GoogleChrome/chrome-app-samples to get more an idea of the shape of the platform.
I have developed an Ubuntu desktop application to monitor when computers are on that is currently writing directly to a MySQL database. For security purposes I assume that I don't want to have all of these clients talking directly to my database, and instead need to create some other web interface between the client and the database. Should I write this interface in PHP? How does the client invoke this interface?
For security purposes I assume that I don't want to have all of these clients talking directly to my database
Probably not. You can lock down the database to some degree, but probably not enough.
instead need to create some other web interface between the client and the database.
Web services are the usual way to provide a controlled interface to a database these days.
Should I write this interface in PHP?
You could. Language should is a fairly personal thing though. I'd probably go with Perl's Dancer framework myself. It is capable of handling a RESTful API (although that guide assumes you've already learned the basics of Dancer).
How does the client invoke this interface?
By making an HTTP request. It might be as simple as a POST request with on as the body (and then the server uses the client ip address to determine which machine the request came from). The specifics of how you go about that depend on the language you are writing the client in and the libraries you have available to it.
I want to use PHP (Symfony2) because building apps with it is quicker than building apps w node (IMO). I want the speed and scalability of node, however. My proposed solution is to use node to handle all of the app's data. I would then use Symfony2 as a client to node and pull any data I need from the node server's REST API. I could then connect to node directly with my iOS/android app and take advantage of its scalability. Is this a viable solution? How can this be improved?
What makes Symfony or any Rails inspired framework fast to develop is the scaffolding.
By using Node for the backend to handle the data management (API), you are loosing all of that, and keeping only the VC (View Controller) of Symfony's MVC. And you won't get any faster if you only keep those and add the mess of having 2 backends.
They are some Rails inpired frameworks for Node.js out there.
Railway is one of them.
If I understand you correctly you want to know.
a). If you can build a API server with nodejs. The obvious answer is yes.
b). If your PHP app can get data from the nodejs api server. Again yes you can do this.
c). If your mobile app can get data from the nodejs api server. 3rd time yes.
But understand that you now have to deal with two separate server-side technologies\langauages.
You will have to weight-up if this "quicker" or "more maintainable" then building both applications using the same stack.
I have some experience building web applications in html, css, javascript, jquery, and php. I understand what a wsdl document is made up of. I have been tasked to invoke a web service, which will then send an email that says "hello world."
After some hours of research, I've come across things like Apache Axis, XML-RPC, Open ESB, and Mule. Do I have to know java in order to invoke web service->send email? Is there a way to invoke a wsdl from within a web app using php?
I know about the mail() function in php. But I have been specifically told to learn how to invoke a web service. I'm lost and don't know where to begin.
I'm going to research Apache Axis until I figure out what to do.
Do I have to know java in order to invoke web service->send email?
You can create a web service using any web/server-side languange. But you should understand what is "Web Service", at the firs place, before you go too far with your question.
And stop thinking that Web Service = XML = Java.
I know about the mail() function in php. But I have been specifically
told to learn how to invoke a web service. I'm lost and don't know
where to begin.
Web services are starting to get fairly popular, but are not often well understood. When we talk about web service, we mean interfaces to data offered via HTTP, designed to be used programatically. With these loose definition, RSS feeds (also) appear to be a web service too since they share data across HTTP in format intended for parsing by software rather than humans, altough they're not usually included in such discussions.
Web service has become a label for XML sent over HTTP with read and write capabilities (but this is not the entire picturre). While HTTP always sit at the core (putting 'web' into 'webservices') we don't necessarily need to use XML, nor do we need to provide methods to write data. Many web services only allow querying and reading data.
While we already have a transport layer in our networking stack (TCP/UDP), then when we talk about web service (which actually an API on the top of HTTP), then we also need an API transport layer. When we talk about API transport layers, what we actually mean is a layer above the application layer at the top of OSI seven-layer model. Shortly, there tend to be three main contenders in this space,
A. REST
B. XML-RPC
C. SOAP
After you create your own public API, using ones of above transport layer, you can then encourage people to building with more outlandish languange and applications to build their own API kits, by providing the core set of languange support (PHP, Perl, Phyton, .NET, and Java).
So where is sending email in these explanation? Its just a part (a little one) of what you called "Web Service". After you have enough playing with "Web Service", then you will know exactly where you can put that as part of your Web Service.