Home

LCS

A registration backend primarily for hackathons. This sits on the web as an API that lets you integrate a website and mobile applications. We also support QR-code based registration so that hackers (or attendees) can sign-in at the event using QR codes.

We hope that anybody can use this API throughout the hackathon - even hackers to enrich their apps with live data.

This code base is a bunch of AWS Lambdas. Hence, the entire backend is designed to be deployed without a server. We rely on AWS to provide the hardware at the right time - we're using FaaS (Functions as a Service).

Why LCS?

It's called the Ludicrous Card System since, ludicrously, it's run two hackathons, and the goal is for frontends (apps, sites, bots, commandline interfaces, a plugin into Tony Stark's JARVIS, etc.) to have a "card" system where information is formatted into cards and the most relevant ones pop-up as needed. Emphasis on the double-quotes: these cards are an idea, not physical (or CSS-based) cards. By having the API, we hope to facilitate providers of information - to help them guarantee that they're displaying information to the right people at the right time.

When LCS?

We should respect our history. See history for more!

This is the current end of a long line of HackRU backends and websites.

The Users of LCS

We expect different types of users and this guide caters to you differently based on your use.

LCS is essentially a library - an API - so you're either using the API or making your own version of it.

Just Using the API

This is intended for people within the same hackathon or event. This means you're trying to provide some separate service for registered users.

You'll read the data and manipulate things the API lets you.

The instructions are partitioned into an example, general ideas, and an API doc.

Making your own version

This is if you're running your own registration and don't want data from other events using LCS. Then you need to worry about a lot of features and third party APIs our API uses.

You'll also be able to make policy decisions. We'll let you know about those.

we have a Getting Started / Deploy guide.

see the old deployment instructions for more/potentiality inaccurate information and a quick overview of the codebase.

The Future

We hope there is one...

There are a few small features that need testing and one that needs existence.

Otherwise, the key goal is maintenance and documentation.

Nutritional Information

Salt content: 35% recommended value based on a 2000 Calorie diet.