Uh Oh! It appears you're not connected to the internet!
Sorry! We currently have more users than we can cope with. You can either wait until a space becomes available or come back later. We will be upgrading our servers to cope with this soon!
You got the boot! Click to connect back up...
Please contact an administrator, You are not authorised to login via this IP address
Already have an account?
Click here to login
Don't have an account?
Click here to sign up
Go check your email!
Oops! We don't know your email address, We can't send you a new password! Contact an Admin
Set Profile Picture
Select An Image
Confirm End Of Friendship
Chat To Us
Prefer to chat anonymously?
Read all about it, See what the good people at Project Peach have to say
Need a quick, non technical primer about our live WebApp architecture?
Live WebApps: #101, Our Architecture
Live WebApps: #101, Our Architecture
Need a quick, non technical primer about our live WebApp architecture? Here's a quick birds eye overview of what makes our live WebApps tick and what makes them really special. This is how we bring your website and mobile app alive.
Cloud WebApp, Browser UX (User Experience)
Our live WebApps run up in the cloud and not in your browser. They live alongside a normal web server. We've built a ton of code, called a framework, that has lots of existing code that helps us build your WebApp really quickly. Your WebApp application is running all the time up in the cloud, it never stops. Only the user interface, the forms, controls, buttons live in the browser. Whenever you interact, type or tap, our controls, for example typing in a search we simply send your request on to the WebApp in the cloud. All your actions causes messages to be sent. The results of your actions, like the search results, come in messages received from the WebApp. We keep a constant connection between the browser and the WebApp so that we can communicate and send messages in both directions, from browser to server and visa versa.
An Example: As You Type Searching
Let's work it through with an example. Let's say you hit the search box and begin typing to filter the results. When you take a micro break from typing we send a search command, called an app message, up to the WebApp on the server. The WebApp listens all the time for inbound messages coming from connected clients, your browser is just one connected client, other user's browsers are also connected clients. Each browser looking at your WebApp is constantly connected. So, returning to the example, when the WebApp receives the inbound search 'app message' it processes the command and returns the results in another message, an outbound message. The user interface code running in the browser picks up the message and displays the data in the target control. That's it! Well it's a little bigger than that but that's the essence.
Shared Code, Shared Data
Let's examine in a bit more detail. Since all users, clients, browsers, are connected to the server hosted WebApp we have both shared code and shared data. What this means in simple terms is that the actions of other connections is available to ALL connections. We run the same code and can share the same data. Not getting it? Consider two remote users in two browsers both editing the exact same data in the same browser user interface form. A WebApp knows that this is happening because both users register an interest in the same shared data. We can do really cool things using this technique. If the first user starts to type then those changes are reflected in real-time to all observers. You see other user's changes live as they type. Everything we do is like this. Our WebApps know who is watching what data and reflect any changes live. The data in your browser is always correct and up to date with other user's changes.
An Application Messaging Hot-Rod
Our server hosted live WebApps are app message processing hot-rods. We don't handle one message at a time we deal with them concurrently. We've a cached, threading model, second to none. We've an army of little workers all handling tasks at the same time. We've a queue of idle workers waiting to process messages, both inbound and outbound. Our admins can fine tune the number of available workers live to tailor to demand. It's so fast we profile (speed test) our code in μs (microseconds - millionths of a second). We use this speed to power global head to head gaming in our bitcoin for gaming WebApp http://cashclamber.com
An Example: Live Updating Post Search Results
Let's hit another example. What if you've searched for a product and an admin adds exactly what you're looking for? Simple. Your search filter has registered your interest in a matching product in the server WebApp shared data. An admin adds a matching product. Bingo, your search is still alive watching for updates which creates an outbound message that 'pushes' the new product into your existing search results. There's no need to refresh with live shared data. You never miss a new product even if you've already searched.
How's our WebApp Security
We've a whole arsenal of security built into our in-browser coding. We obfuscate and minify it rendering it unreadable. We've added a layer of our own security over our constant live messaging connections. We've no WebApp source code stored on the server either, it's just a runtime application. Does our security work? We host a live bitcoin honeypot WebApp that runs 365/24/7 to test our security. We soon know about security problems. CashClamber.com has been running for nearly five years now.
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.