Dimensional Data

History on Client-Server Apps When the original web first came into widespread public use things were reasonably basic. Webpages were effectively specialized documents, like a library. Users clicked on links to articles they found interesting. Somewhere, perhaps on another side of the world, another computer or server was the destination for that click or as we came to call it: the request. The user sends a request and, the server, the far-off computer, gives a response back to the user for every request. That response was typically formatted text, images and later, movies and music. Editing web pages was done mostly using plain text editors rather than more advanced ide software. After several years and a few iterations, Web 2.0 emerged allowing a more interactive, programmable kind of web page which behaved more like an application. The process was asynchronous and, we were able to execute commands on databases and manipulate the data they contained in that way. Like, create a user, get all users and delete a user.  With the advent of Web 3.0 and beyond, a new concept applied to the systems is a continuous connection between a client and a server. Web applications could now carry out significantly complex tasks, interact with specialized hardware like GPS sensors and other activities rivaling traditional desktop application capabilities. Along with this rose the need to implement real-time connections which transmitted data between the web browser and servers in an optimized and highly efficient way. The connection between the server and client can be used on either side to update and set the state and react accordingly. We refer to that highly interactive nature as “real-time web applications”. They’re a long way from those original electronic reference type documents of the original web. What methods are there for implementing real-time web applications? Interval polling  This method is very straightforward. We go to the server and see if we have anything we need to do in the interval. And there are 3 cases: Nothing will be returned The server has data that return to us Some sort of internal server error But no matter what, we go to the server to see if we can do anything. Problems of interval polling More connections, more overhead Mode bandwidth The server can’t keep up with the request Long polling As you can see, we were making requests every 10 seconds no matter what. Long polling is a call that we open up and remains open until the server has something for us (depending on browser timeouts). And after a timeout, we open up our request all over again. Benefits of this method: Less server overhead and resource consumption The downside is we still make and open connections regularly.  Server-Sent Events  In this method, we open a connection to the server and, that server can remain open indefinitely. And server makes use of this connection or pipe to send us messages.  The best thing about this is the server can push data to the browser without requiring multiple connections. But this is one way in which the client cannot send messages to the server. Web Sockets Web sockets are the ability of the client in the server to open a one-on-one connection, which they both can send data over.   What are the benefits of Web Sockets? Bi-directional communication […]

What is REST and why should I learn more about it? REST is a type of software architecture that was designed to ensure interoperability between different Internet computer systems. Basically, the idea is that services that comply with REST architecture can more easily communicate with one another whether you are designing mobile apps, Linux, macOS or it purely native windows development. REST stands for representational state transfer and it was proposed by computer scientist Roy Fielding’s 2000 PhD thesis, Architectural Styles and the Design of Network-based Software Architectures, in which he introduced and described REST. The goal of REST is to increase performance, scalability, simplicity, modifiability, visibility, portability, and reliability. This is achieved through following REST principles such as a client–server architecture, statelessness, cacheability, use of a layered system, support for code on demand, and using a uniform interface. Where can I download Roy Fielding’s Original PhD thesis about REST? You can have access to the complete original Roy Fielding’s 2000 PhD thesis here! Since long time ago Mr. Fielding was deeply involved in the web’s early development and standardization, he began working at and for the World Wide Web Consortium in 1994 and co-authored the HTTP 1.0 specification. Later he was the main author behind the HTTP 1.1 and URI specs also co-founded the Apache web server project. The name “Representational State Transfer” is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. Fielding’s approach was to make sure that the REST architectural style emphasises the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching components to reduce user-perceived latency, enforce security, and encapsulate legacy systems. What do the different REST terminologies mean? REST does not enforce any rule regarding how it should be implemented at lower level, it just put high level design guidelines and leave you to think of your own implementation. What we do have is the definition of 6 architectural constraints which make any web service – a true RESTful API. Client–server: By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components. Stateless: Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. Cacheable: Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests. Uniform interface: By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of […]

Cryptocurrencies like Bitcoin use enormous amounts of energy to secure their network. But why are cryptocurrencies so power-hungry and more importantly what are the alternatives? Much of the hardware used to perform the calculations uses highly specialized computers running Linux collaboratively in “farms” although there are many crypto “mining” apps which are Windows based or uses Windows program development even if their eventual targets are not Windows-based machines. Why is proof-of-work a problem for Bitcoin? Mining new coins take a lot of computing power because of the proof-of-work algorithm. The concept was first presented in 1993 to combat spam emails and was formally called “proof-of-work” in 1997. Nevertheless, the technique went primarily unused until Satoshi Nakamoto developed Bitcoin in 2009. He discovered that this mechanism could be used to reach harmony between many nodes on a network, and he utilized it as a way to secure the Bitcoin blockchain. Yet the proof-of-work algorithm works by having all nodes solve a cryptographic puzzle. This puzzle is solved by miners (the metaphor is drawn from the concept of them extracting their fortunes from hard physical work) and the first one to find the solution receives the ‘miner reward’. This has directed to a situation where individuals are building bigger and larger mining farms in order to share the effort in a “many hands make light work” team effort. The advent of lower cost hardware with a more affordable “bang to buck” ratio – more CPU power for a given financial outlay – coupled with a very broad expansion in the availability of single board mass-produced hardware such as the Raspberry Pi and RISC-powered boards has meant these kinds of mass-computing networks are achievable at a modest level of investment. Bitcoin miners alone use almost 54TWh of electricity, enough to power 5 million households in the US or even power the whole country of New Zealand Will blockchain contribute to global warming? Maybe. Blockchain calculations are shaping up to become a power-suck of worrying proportions. Even accounting for the lower power consumption of modern hardware the sheer computational effort involved and a trend toward coupling dozens, hundreds or even thousands of machines together to obtain the financial rewards which, due to its nature is increasingly hard to obtain and, in the case of Blockchain, harder means more CPU cycles and more CPU directly translates into a greater demand for electricity. According to Digiconomist, Bitcoin miners alone use almost 54TWh of electricity, enough to power 5 million households in the US or even power the whole country of New Zealand. But it does not halt there.  It’s currently a simple equation: proof-of-work gives more bounties and thus greater rewards, to people with better and more plentiful equipment. The higher your hash rate (the number of calculations you can perform on the data), the higher the chance that you’ll get to create the next block and obtain the mining reward. To increase the chances even further, miners have come together in what’s called “mining pools”. With mining pools, they combine their hashing power and distribute the reward evenly across everyone in the pool. Proof-of-work is causing miners to use massive amounts of energy and it encourages the use of mining pools which makes the blockchain more centralized as opposed to decentralized. So, to solve these […]

What is Ethereum and how is it different to Bitcoin? Whether your focus is on native windows development or for mobile, cross platform targets, Ethereum is the community-run technology powering the cryptocurrency ether (ETH) and thousands of decentralized applications. Ethereum is widely called “the world computer” or “general-purpose blockchain”. Ethereum is an open-source platform written on smart contracts. It keeps smart contracts on blockchain and charges every time someone wants to alter something in the code by taking fees known as GAS. You can build anything with Ethereum, from websites to applications and games. Ethereum is different in many ways from Bitcoin, and you can do more with Ethereum. You can make any type of program in Ethereum because of its Turing complete feature. Moreover, Ethereum tracks the state of data stored on the blockchain. The data is in key-value pair which, means if the value is “Delphi” the key will be “c++builder”. This even runs the code and stores the data with the help of Ethereum Virtual Machine (EVM). Additionally, in Ethereum, the state changes when all the participants agree with each other to avoid fraud or misuse of the system. How can I start building Ethereum Apps with Delphi? First of all, Delphi is a development environment where you can build and compile native applications for Windows, iOS, macOS, Android, and Linux. Delphereum is a Delphi interface to the Ethereum blockchain that allows for the development of native dapps (decentralized applications). Delphereum supports every EVM-compatible network, including (but not limited to): Arbitrum Optimism RSK xDai Binance Smart Chain Polygon What is a smart contract? A smart contract is a calculation that takes place on a blockchain or distributed ledger. You can think of a smart contract as a microservice that operates trustless on the backend of your application. Smart contracts can have many applications, ranging from sports betting to online voting. But the true power of smart contracts is in managing assets that have value and are scarce. Once added to the blockchain, a smart contract becomes public and cannot be modified or removed. This assures your users that the rules are transparent and will never change.  What is a dapp? DApp – dapp -> is an abbreviated form for decentralized application. A DApp has its backend code running on a decentralized peer-to-peer network. Contrast this with an app where the backend code is running on centralized servers. A DApp can have frontend code and user interfaces written in any language (just like an app) that can make calls to its backend. Furthermore, its frontend can be hosted on decentralized storage such as Swarm or IPFS. How to start developing DApps with Delphi and Delphereum? We have been serving you valuable posts and tutorials about Blockchain technology, and I would like you to check out some of them here. Then we have a set of tutorials that you can follow to learn how to: connect Delphi to a local (in-memory blockchain)? connect Delphi to the Ethereum main net? connect Delphi to smart contracts? create smart contracts with Delphi? create Ethereum-signed message signature in Delphi? transfer ether with Delphi? and more. You can find them from this tutorial:  What is the best way to learn how to use Ethereum, Bitcoin and other cryptocurrencies in my apps? The best way to learn real-World case studies is to continue […]