I have been using C# with the Newtonsoft.Json library to collect data from Facebook. This is working reasonably well for me, but now I would like to see if I can do something similar with F# instead of C#.
I note that F# 3.0 (now in beta) has support for type providers, which have the potential to make access to loosely structured data like Facebook much easier.
Does anyone know of an F# sample showing how to get Facebook data?
Since you mentioned type providers: FSharpx has a JSON type provider, but I think it currently works with local files only, not with a JSON fetched from a HTTP request. You're welcome to join the project and help us with this!
Related
I am starting to learn developing web interfaces that can add and retrieve data via blockchain. The data is not in the form of cryptocurrency but rather in something like name and ID number.
I have also learnt about metamask, ganache, web3, truffle, javascript, html, css, node.js, solidity, smart contract and json...but I am not sure how to link all of them for adding and retrieving data via blockchain. I have done some googles and youtube, but unfortunately, I could only understand a few of them. Can you help me in explaining the interactions between blockchain and web interfaces to adding and retrieving data, and how to achieve it?
Web3 is used for all the purposes you've described above. Once you've retrieved the data, you can store it in a variable and use it in your frontend applications as well.
Here's a reference diagram : Link
If you are too lazy to read documentation, here are a series of good examples. They were very helpful tutorials for me.
I have been given a task to do using Ember JS however I can't find any documentation or a direction to point myself in in regards to getting a feed from a API URL - Like you can do with Curl in PHP.
I do no that I will possibly have to store it in Ember Data.
Can someone give me a brief example of what I should be doing - It would be great
EmberJS functions completely differently in how you would contact an API in Curl or PHP.
For starters - in emberjs you are contacting API's straight from the client (and this matters, because there are cases where people use backend code such as PHP to call a third API with a secure, org-level API token. This type of thing should not ever be handled by ember or a single page web app. Keep it in your backend code!
Now to get to the really exciting part about ember - Ember Data.
Ember Data in its own right is a rather complex subject. To simplify, ember stores data in what is known as the Data Store, or DS. The DS API is rather large and very much worth getting familiar with. The store is backed by Models and these models can even form relationships much like a directed graphing database would.
The store operates, like all of the ember I know, on the principle of convention over configuration. Thus, the store receives data most efficiently from a conforming RESTful API through the use of the ember RESTAdapter. However, RESTAdapter API is an extension of Ember Adapter and both are easily customized to suit your needs. I can't mention the RESTAdapter without highlighting the importance of the use of serializers. Serializers are integral in doing just what their name implies - serializing (and normalizing) the data coming in from the server into a JSON-parsable object that conforms to the conventions that the adapter expects.
In my experience I usually have to do some kind of customizing at either the RESTAdapter or Serializer level - more commonly the latter as opposed to the former. I also strongly recommend really getting familiar with Ember Data and the Data Store in its entirety as all this in combination provides you with a tremendous amount of power that brings with it new and interesting design paradigms in efficiently integrating with a REST API.
So the only remaining question is - So when do I call the API? Well - that's the cool part. In configuring your adapters, serializing, setting up models you've kind of done the whole shebang. Throughout your webapp you can now just rely on the use of models connected to the ember data store - and ember is going to take care of the rest (such as knowing when to make an API call).
Anyway, I don't want to fanboy ramble too much. Take a look at their excellent documentation on the topic of Models at their site. Also, take a look at ember-cli! If you're just getting started with Ember, this is most certainly the way to go. Don't expect this to be a short learning curve - ember has a steep learning curve and you are stepping right into the heart of it with your assignment. You will find that once you wrap your head around the use of the store it's an incredibly empowering tool.
Good luck with your work!
I'm currently wrapping my head around Ember.js and converting a previously written PHP application, that application made use of of mysql database and some basic PHP code to display results.
There was a whole bunch of javascript to create interactions, but all that code quickly became unusable.
I have most of my frontend stuff done in Ember.js and started thinking about how I should get started with the backend.
There's not that much data involved, uses can request data, create new data, change data or delete data.
There would be a small part where I would like to get data in real time.
I've looked around on the web, but since it's all relatively new, there's not that much information out there.
I would recommend implementing a RESTful API in PHP and hooking your frontend up with that API. You can use your ember code to handle all user interaction, and then when some actual data needs to be changed send a request to your backend.
I have made apps in the past using this strategy with a Laravel backend which makes it very simple to set up RESTful interactions.
You can read about Ember + REST here: http://emberjs.com/guides/models/the-rest-adapter/
The question is quite vague as you could do it in a thousands different ways.
It doesn't matter which language you use for the backend as the ember app won't care.
The only thing you need for the Ember app to work is a decent REST api.
For resource about best practices, check this
Some examples:
In php: http://davss.com/tech/php-rest-api-frameworks/
In Rails: http://railscasts.com/episodes?utf8=✓&search=api
In Node express: http://blog.modulus.io/nodejs-and-express-create-rest-api
As a Saas: https://www.firebase.com
I have been living with an EmberLoopSql stack (pronounced ember-loop-cicle - just cause I like the sound) for 4 months now and am digging it muchly.
StrongLoop allows you to reverse engineer your datastore, creating models that correspond to tables, and automatically creating a CRUD ReST API for them. This means there is no code in your API, just configuration.
Add the loopback-component-jsonapi to StrongLoop to provide json:api compliant responses.
Next, add relationships to your StrongLoop models - like bubbling up the foreign key relationships from the datastore to the api. Now you have json:api responses that Ember really loves.
I am a big fan of Percona Server (MySQL replacement) and if you de-normalize your tables to align with your application, you have one of the main advantages of a NoSQL style datastore. But if you really like something like Mongo (I do), StrongLoop has a data juggler for that.. as well as for most modern datastores.
Ember's new JSONAPIAdapter recognizes relationships exposed in the json:api responses from StrongLoop. After setting up relationships in your models - again bubbling up datastore foreign keys - Ember will fetch dependencies automatically for you. E.g. If you have model a,b and a hasMany b, you can use a.b in your templates and Ember will understand the relationship and fetch the data for you.
What I really love about this stack is how much boilerplate code just evaporates. Compared with java, php, express, go, etc. the code in this stack is small and well organized. I can implement new features in a couple of hours instead of a couple of days.
Hope these opinions help...
In the project I am working on, we are using ember.js (1.0rc1) without ember-data which is working out quite fine so far. The reason why we decided to go without ember-data is that we already have some utility methods to handle the integration with the REST interface, and over all because ember-data is not part of the ember.js.
From emberjs.com:
Currently, Ember Data ships as a separate library from Ember.js, while
we expand the adapter API to support more features. The API described
in this section tends to be stable, however. Until Ember Data is
included as part of the standard distribution, you can get your copy
from the GitHub page.
So, to my questions and the input I am looking for:
how much do we lose/gain with this approach? (besides the REST integration)
experiences of somebody that actually might have started also without ember-data, and now migrated to ember-data
maturity of ember-data and its integration into ember.js
And there is another question, which might rather be for the ember.js/ember-data devs:
what's the roadmap to integrate ember-data into ember.js and how strong will be the impact on the APIs?
Thanks for sharing your experiences and giving some hints and advices. // ph
I use ember-data in my project and I'm very pleased with it. I saves you a lot of time developing your own stuff for communicating with the server.
At this time ember-data is not officially production-ready but I use it already.
Read this on the emberjs website about ember-data. It says:
Without any configuration, Ember Data can load and save records and relationships served via a RESTful JSON API, provided it follows certain conventions.
We also understand that there exist many web service APIs in the world, many of them crazy, inconsistent, and out of your control. Ember Data is designed to be configurable to work with whatever persistence layer you want, from the ordinary to the exotic.
There is more information on the github page. There is even kind of a roadmap in it...
Another advantage is that you can define your Models with their relationships. It's also possible to use transactions which are giving you the ability to rollback changes if something went wrong at the server.
I really like the vision behind ember-data that it's not dependent on the kind of backend you use. Or where you define your relationships. If you use Mongo-db where you define the relationships on the parent object, where others do that the childs.
Can some people offer some light on the following questions? I believe that the following questions are very much debatable, but I just want to know the mere facts which will enlighten me & of course many others viewing this general question post.
Why does Magento API produces Web Service Responses in XML format & not in JSON format? There should be some advantages in producing the responses in XML format. I want to know those advantages mainly.
In Magento terminology, there are two API versions mentioned - "Normal API" (api/soap) & "API v2 (api/v2_soap)". What's the difference (mainly the advantages) between these two versions, & where does WSDL fit in?
If I'm to create a new Web Service, should I be targeting SOAP v1 format, or the SOAP v2 format, or both of these formats?
Can the Web Service create a general definition of WSDL, based on my requirements, in Magento? What I want is that I want to know whether the "wsdl.xml" file (residing in the "etc" folder of the Magento module) for any particular Magento API module can be generated dynamically? If I provide my required API method name, along with all the property names, types, and also the Response data types, then will I get the "wsdl.xml file dynamically generated with all the Complex Types & Methods & Messages properly mentioned?"
If possible, please provide some good links, from where this spider-webs of Magento Web Services can be thoroughly cleared.
Also, please consider my expertise in this field of Web Service as a novice one, so that based on any valuable input, I can re-frame the question.
Help appreciated & thanks a lot to everybody.
My Main point of asking this question is that I want to make new custom APIs which can be used by any systems, whether it be ERP / CRM / SAP / Cloud / anything in general.
P.S.
I tried posting this question in the Programmers Stack Exchange area, but due to the lack of available required tags (like magento, wsdl & soap), I had to post it here. If possible & required, please transfer this question to proper stack exchange area.
API is not for ajax(frontend), but to integrate Magento (frontend shop) with different ERP, CRM, SAP (backend tools) systems - to import data and get reports. That's why it's using XML.
This is not magento's terminology. This is done mainly for legacy support. So you have to use lates one - v2.
What means general definition of WSDL? WSDL describes published functionality - available calls/resources. If you don't need it you need to overwrite configuration files to not publish everything but only necessary ones or do this form admin area.
Could you tell more clear and more technically what do you need to do with API?
The API works great for normal PHP programming where you want to get something out of Magento. 'Normal' API works fine with PHP, furthermore, the resultant XML is very easy to work with in comparison to the XML that gets churned out by other APIs.
Some people have said that the Magento API is slow, which it is. However, if you move the same code into a Magento program then it still takes forever, the API code isn't much of a burden.