Laravel development for Perth mining and resources businesses

Perth's resource businesses create data in places with no connection, and that single fact reorders every assumption a backend normally makes.

A record is written on a device in a pit, a workshop or a vehicle. It exists for hours before the server hears about it. When it arrives, it arrives alongside others created after it, sometimes twice because a sync was retried, and sometimes conflicting with an edit somebody else made in the meantime. None of that is exceptional - it is the normal operating condition.

A Perth site device generates the identifier

This is the first decision and it determines whether everything else is possible.

If the database assigns identifiers, an offline record has no identity until it syncs. Nothing can reference it, a related record created on the same device cannot point at it, and a retried sync produces two rows because the server has no way to recognise the second submission as the same thing.

A UUID generated on the device fixes all three. The record has an identity the moment it is created. Related records reference it offline and arrive as a coherent set. And a unique constraint on that identifier makes the sync idempotent at the database level, which is the only place the guarantee actually holds.

That is the same principle as handling a message that arrives twice anywhere else, and Laravel's queue retrying by default makes being safe to run twice a structural requirement rather than a precaution.

Perth sync conflicts need a rule per field, not a default

The part most offline systems skip is what happens when two devices edited the same record.

There are four honest options - last write wins, first write wins, merge at the field level, or keep both and ask somebody - and the right one differs by field. A free-text shift note can merge. A status can take the latest. A measured figure cannot be silently replaced by a later sync from somebody who was looking at stale data, because the later write is not the better one in that case.

So the rule is decided per field or per record type, written down, and anything that cannot be resolved automatically goes into a queue a person works through. A system that quietly applies last-write-wins to everything will lose somebody's work and nobody will ever know which.

Two Laravel timestamps, and reports have to choose

The third consequence is the quietest and it shows up as reports nobody trusts.

A record created at six in the morning and synced at two in the afternoon has an occurrence time and an arrival time. Almost every report wants the first. Almost every default uses the second, because created_at is set when the row is inserted.

Storing both, naming them clearly, and being explicit about which one each query uses is the entire remedy. Without it, a day's production appears to have happened in the afternoon, a shift report is attributed to the wrong shift, and somebody spends a week deciding the data is wrong when only the timestamps were.

A Perth shift report is submitted once and corrected later

Work is recorded at the end of a shift by somebody who wants to go home, and reviewed the next morning by a supervisor who finds two errors in it. Both the original and the correction matter.

The original matters because it is what the operator recorded, and in an environment with any safety or compliance dimension that is evidence. The correction matters because it is what is true. A system that lets the supervisor edit the submission in place has destroyed the first to produce the second, and the person who submitted it has no way to show what they actually reported.

So a submission is immutable once made and an amendment is a new record referencing it, with the author, the time and the reason. The current view of a shift is the latest amendment; the history is available and nobody has to go looking for it in a log. This also settles the awkward conversation about who may amend, because amendment is a distinct action that can carry its own permission rather than being indistinguishable from data entry.

Submission from a device adds one wrinkle worth planning for. A report queued offline and synced two days later arrives after the shift it describes has been reviewed, which means the system has to accept a submission whose period is closed and flag it rather than refuse it. Refusing it loses the data; accepting it silently corrupts a reviewed period. Flagging it is the only answer that keeps both.

Laravel uploads from a Perth site with almost no bandwidth

Photographs are the point of most site records and they are the part a satellite link cannot carry.

Which means the record and its attachments are decoupled. The report syncs first, as text, because it is small and it is the thing head office needs. Its photographs upload afterwards, individually, resumably, and the record is usable in the meantime with the attachments marked as pending. An application that treats a record as incomplete until every file has landed will show nothing at all for two days.

Resumable uploads are not optional on a link that drops. A file sent in chunks, each acknowledged, with the client able to resume from the last confirmed chunk, survives a connection that fails at eighty per cent - and a single POST of a twelve-megabyte photograph over a marginal link will fail at eighty per cent repeatedly and consume the bandwidth each time. Server-side that means an upload session is a record with its received chunks, assembled on completion and verified by checksum against what the device said it sent.

Resizing happens on the device, before transmission, which is the single largest saving available. A full-resolution photograph is rarely what anybody looks at, and sending a bounded version with the original retained locally until it can be uploaded cheaply - or never, by policy - turns an impossible sync into a routine one.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - the privacy and breach regime, hosting, invoicing - is on the Australia market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption.